DIP23 draft: Fixing properties redux

Timon Gehr timon.gehr at gmx.ch
Mon Feb 4 07:32:43 PST 2013


On 02/04/2013 04:02 PM, deadalnix wrote:
> On Monday, 4 February 2013 at 14:25:10 UTC, Timon Gehr wrote:
>> On 02/04/2013 03:05 PM, Andrei Alexandrescu wrote:
>>> ...
>>> Couldn't AddressOf use "&(" + exp + ")"?
>>>
>>> I thought more about this. The problem remains even without @property,
>>> due to optional parens in function invocation. Consider:
>>>
>>> ref int fun() { ... }
>>> auto p1 = &fun;
>>> auto p2 = &(fun);
>>> auto p3 = &(fun());
>>>
>>> What are the types of the three? The optional parens in invocation
>>> require some disambiguation.
>>
>> The obvious rule is not to give significance to redundant parentheses.
>>
>>> I think the sensible disambiguation is to
>>> have &fun take the address of fun and the other two take the address of
>>> fun's result.
>>>
>>
>> No! &fun and &(fun) are the same thing. Functions that get their
>> address taken are not implicitly invoked. (Again, Scala agrees.)
>>
>
> Scala don't really agree. fun is the function pointer. It is evaluated
> if the function pointer is a NOOP, but that's it.

Of course Scala agrees.

scala> def foo() = 2
foo: ()Int

scala> foo
res0: Int = 2

scala> foo _
res1: () => Int = <function0>

scala> (foo) _
res2: () => Int = <function0>

scala> def bar[A](arg : A) = arg
bar: [A](arg: A)A

scala> bar(foo)
res3: Int = 2

> Here is scala semantic
> with D syntax :
>
> void bar() {}
> bar; // execute bar. Is an exception because taking the function pointer
> is a NOOP.
>

No, it is the rule.

> void foo(void function() bar) {}
> foo(bar); // OK, bar is not evaluated.

This is the exception. (That nobody has argued in favour of so far.)


More information about the Digitalmars-d mailing list