On 2/5/13 11:44 AM, Steven Schveighoffer wrote:
On Mon, 04 Feb 2013 18:18:16 -0500, Walter Bright
<[email protected]> 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
