On 2/5/13 2:05 PM, Steven Schveighoffer wrote:
On Tue, 05 Feb 2013 13:33:35 -0500, Andrei Alexandrescu
<[email protected]> wrote:
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.
What about structs that live on the heap? e.g. a struct element of an
array, or a struct member of a class instance.
In that case we'll disallow it conservatively.
I think the point about @safe code is moot, aren't pointers disallowed
in safe code anyway?
Yah, time to start enforcing it more seriously. But we want to ban some
uses of & in all code.
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 think a cast would be sufficient:
cast(int *)(&refparam); // understood that a cast is required
To jump through this machinery to turn a reference into a, um...
reference, seems like a huge waste of code space and resources.
The whole point was to avoid using operator &.
Andrei
