DIP23 draft: Fixing properties redux

[Andrei Alexandrescu]

On 2/5/13 11:44 AM, Steven Schveighoffer wrote:
> On Mon, 04 Feb 2013 18:18:16 -0500, Walter Bright
> <newshound2 at digitalmars.com> wrote:
>
>> On 2/4/2013 6:05 AM, Andrei Alexandrescu wrote:
>>> Couldn't AddressOf use "&(" + exp + ")"?
>>>
>>> I thought more about this. The problem remains even without
>>> @property, due to
>>> optional parens in function invocation. Consider:
>>>
>>> ref int fun() { ... }
>>> auto p1 = &fun;
>>> auto p2 = &(fun);
>>> auto p3 = &(fun());
>>>
>>> What are the types of the three? The optional parens in invocation
>>> require some
>>> disambiguation. I think the sensible disambiguation is to have &fun
>>> take the
>>> address of fun and the other two take the address of fun's result.
>>
>> The only time it is valid to take the address of a function's return
>> value is if the function returns a ref.
>>
>> But I also would think that it's a suspicious practice to take the
>> address of a ref. We've disallowed it in other circumstances, why
>> allow it here? If a function intends for someone to take the address
>> of the return ref, shouldn't the function return a pointer instead?
>
> I'd agree with you if we could have ref variables. In some cases, taking
> the address is the ONLY option.

Walter and I reviewed the discussion and had a long talk. We are very 
seriously considering banning the use of & against a ref result from a 
function (and actually ref parameters and even struct members in @safe 
code). One would still be able to take the address of a field in a class 
because that's assumed to live on the GC heap.

To get the address of an object in @system code without resorting to 
operator& at all, we're considering adding a stdlib function implemented 
like this (there are several other ways, this is just for illustration):

@system T* addressOf(T)(ref T obj)
{
     static T* id(T* p) { return p; }
     auto idr = cast(T* function(ref T)) id;
     return idr(obj);
}

I have a DIP in the making that makes "ref" entirely sealed, i.e. it 
makes it impossible to have a dangling ref in safe code. If that DIP 
gets approved, then DIP23 gets considerably simplified because operator& 
won't be applicable to the result of a function anymore.


Andrei