On Thursday, 7 February 2013 at 06:06:56 UTC, Walter Bright wrote:
On 2/6/2013 7:30 PM, deadalnix wrote:
The limitation on address taking seriously impair the
possibility of
implementing @property properly to emulate a field.
Properties are always going to be subsets of fields. For
example,
@property int foo() { return 3; }
is never going to work with trying to get the address of 3.
Trying to make it work would be a quixotic quest of dubious
utility. I.e. I disagree that it is a serious impairment.
Obviously it is not going to work in that case.
You'll find a huge difference between it will not work in case
XXX and it is impossible to make it work.
It is a given that @properties can't 100M emulate field, but the
goal should be to close he gap as much as possible.
It seems like a solvable problem, as scope can be explicited.
But then, some
address taking are back, and so the syntax problem around
previous DIP isn't
solved (But that is arguably a good thing as we should solve
problems
themselves, not symptoms).
The only time (now) that you can take the address of function
return value is if that is a return by ref. So, if taking the
address of a ref is disallowed, then the syntax is no longer
ambiguous.
It doesn't change anything in many cases. Especially for template
alias parameters. It doesn't change the intrinsic complexity of
the proposal that conflate a function (as first class object),
its return value, and the useless C/C++ entity that is a function.
