optional (), what is done elsewhere

Timon Gehr timon.gehr at gmx.ch
Tue Feb 5 04:02:28 PST 2013


On 02/05/2013 09:17 AM, deadalnix wrote:
> On Tuesday, 5 February 2013 at 07:14:49 UTC, Jacob Carlborg wrote:
>> On 2013-02-04 16:08, deadalnix wrote:
>>
>>> OK, I missed that (I have to say I don't really know that language and
>>> went over it quite quickly). The point that was important to me is that
>>> this is not really applicable to D.
>>
>> I think it's important to the reason why these languages don't have
>> any problems with optional parentheses and why D do have. Otherwise I
>> think this whole thread is kind of pointless.
>
> Yes, this is why I went quickly over cofeescript : it is clearly not at
> all the same thin as D.
>
> Now I think the most relevant one is scala here.
>
> So in scala, funName is a polysemic expression : it is either the
> function or the function's result after evaluation. Scala get from
> context which one make sense.
>
> The major difference I see with scala are :
>   - You have no unary & operator to get address of. Confusion in that
> regard is completely avoided.

You have suffix _ which has a similar role, however it is not overloaded 
to take raw field addresses.

>   - You don't have an intermediate with unexplainable type between a
> function definition and a function (like in C/C++). D try to work around
> that in a poor way. Scala totally remove that concept from the language,
> as it is a source of trouble without any usefulness.
>

The only trouble is that there is no use. We definitely should get rid 
of that. (Don't allow dereferencing function pointers, together with the 
sane parts of DIP23.)

> The main question I ask myself is how that behavior would interact with
> other D features.

The broken is(T==function) would cease to do anything of use.


More information about the Digitalmars-d mailing list