proposal to disambiguate &a.fun: disable optional parenthesis INSIDE &() expression

[FG]

On 2013-02-04 11:20, monarch_dodra wrote:
> As I asked in the other thread: What is the point of even allowing taking the
> address of a property function? If a property is designed as something that can
> encapsulate and emulate a field, then it makes to sense to get the address of
> the getter (As far as I can tell).

Yes, but this is not just about properties but also normal functions:

foo;     // calling foo
&foo;    // delegate of foo
&foo();  // calling and taking address of ref return
&(foo());// calling and taking address of ref return
&(foo);  // OLD: delegate of foo
&(foo);  // NEW: calling foo and taking address of ref return

The change in behavior of &(expr) makes sense in the light that "expr" should
behave the same in every context, not just in &(...), i.e. call foo().

As for properties, they will never be truly exchangeable with variables,
therefore being able to pass around their function pointers is useful.
Naturally taking their address doesn't have to follow the same rules,
but why shouldn't they behave like other functions in "typeof(&prop)"?


> If we already have optional parenthesis, then why even bother having property
> getters? They would end up being exactly the same thing as a normal function...

Indeed, their existence is not essential. They may be more useful when the
operator rewriting is done. The biggest problem is with the amount of code
that uses "prop = x" syntax, which doesn't play well with optional parentheses.

> if "b" is a property, then "a.b" should mean "the thing returned by b",
> *regardless of context*. Simple as that:
> "&a.b"   => address of what is gotten with "a.b"
> "&(a.b)" => address of what is gotten with "a.b"

For me only "&(a.b)" is about the context of "a.b". "&a.b" is something
completely different from "a.b", hence doesn't have to produce same output.