DIP25 draft available for destruction

[deadalnix]

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.