Taking address of properties

[Robert]

> >
> > Read the DIP?
> 
> Stop trolling.
Agreed, sorry. But by reading some arguments that are posted over and
over again, I just get the feeling that people don't even read it, which
is kinda frustrating, as it was a lot of work.
> 
> > It is about encapsulation
> 
> Perfectly possible without DIP26 and encapsulation can be violated using 
> @property as given in DIP26 just as easily as without it.

How?! I mean yeah, you can return a pointer to a field, that is correct.
But apart from that, which might get forbidden too for properties (I
have to think about it first), what do  you mean?
> 
> > and making set functions
> > callable with = in order to be compatible with ref returning functions:
> > (Compatible from set function to ref returning function, not the other
> > way round)
> 
> setter(2);
Fine with me. What is the problem?
> 
> > and for the more expressive syntax:
> > 	a=something;
> 
> That's not more expressive.
If you want to state that the property should assume the given value, it
is. Arguably not more than setA(something), but well it is a nice syntax
and we stay compatible with ref returning functions and with the current
implementation.

> Use UDAs.

True if this was the only reason.
> 
> > The one reason why we can not drop it, is  that = calls the set function
> > on properties.
> 
> So does ( ). And both are the case already.

Yeah, which actually is a good thing, because we won't break much code.
People have their code written according to the implementation not some
specification, so if we keep most currently existing code running and
get sane behaviour, I think this is a good thing, but ok there are
people who seem to disagree.
> 
> > The reason why we should not, is that having such a cool
> > straight forward feature for providing proper no-boilerplate
> 
> Boilerplate can be trivially automated.

Also true, but integrating it into the language makes the property
feature complete and well integrated.