DIP23 draft: Fixing properties redux

[Jonathan M Davis]

On Monday, February 04, 2013 05:00:21 David Nadlinger wrote:
> On Monday, 4 February 2013 at 03:15:51 UTC, David Nadlinger wrote:
> > On Monday, 4 February 2013 at 03:11:25 UTC, Andrei Alexandrescu
> > 
> > wrote:
> >> I really think you are wrong about this. Parenthesizing has
> >> nothing to do with this. &a.b is punctuation that creates an
> >> indivizible unit.
> > 
> > a.b already is an indivisible unit, the result of the function
> > call.
> 
> Actually, let me illustrate this point a bit further, sorry for
> the hasty reply.
> 
> The problem I see is that usually, one can insert grouping pairs
> of parentheses into an expression according to the operator
> precedence/associativity rules at will without changing the
> result. This isn't merely a theoretical exercise, but the way
> (well, in the form of trees) I tend to reason about source code
> intuitively.
> 
> Now, grouping the expression »&a.b« according to the precedence
> rules yields »&(a.b)« – but in your proposal, they mean
> completely different things.
> 
> You could argue that &<expression>.<identifier> is a special
> construct different from the normal address-of operator. But
> where do you mentally draw the line? What about &a.b.c <->
> &(a.b).c <-> &((a.b).c)? &(a + b).c <-> &((a + b).c)?
> 
> Again, from an user's perspective the change in behavior seems to
> be completely at odds with the usual rule in C-family languages
> that grouping parens can be added without changing the meaning of
> an expression. Thus, this part of the proposed syntax strikes me
> as being extremely misleading, which is especially bad because
> the situation with the two possible meanings is confusing enough
> to start out with already.
> 
> And how often do you think you'll find yourself in the situation
> of needing to get a delegate from a property anyway? Can't we
> just make »@property getter expressions are always equivalent to
> their return value« a hard (simple!) rule and add something like
> __traits(propertyGetter, ...) for the rare cases where you really
> need to get hold of the underlying function?

I tend to agree that making the parens change the nature of the expression is 
a bad idea. I'm also concerned that making it legal to take the address of a 
property function is going to cause serious issues when anyone tries to 
actually try and swap between variables and property functions. But there's 
also the issue of it not being terribly common to need the address of a 
property function. The biggest concern there would be what happens when 
someone takes the address of a variable which then gets turned into a 
property. It's not going to work, and the way that that it doesn't work is 
going to vary depending on what & does on a property function and what they're 
trying to assign it to.

- Jonathan M Davis