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.)
