On Thu, 07 Feb 2013 15:14:22 -0500, Andrei Alexandrescu
<[email protected]> wrote:
On 2/7/13 2:13 PM, Steven Schveighoffer wrote:
On Thu, 07 Feb 2013 13:05:50 -0500, Robert <[email protected]> wrote:
Properties provide a means of access control to fields. (Range checks,
only readable, only writable, triggering a signal on change, ...)
So as posted a few times, taking the address of the ref return value of
a property is of no value at all. If you want someone to be able to
take
the address of a field, you should make it simply public (without
@property), because the @property accessor methods won't gain you
anything in this case.
@property ref T front(T[] arr) { return arr[0];}
Not being able to take an address of an array's front element is not a
viable solution. The array range's business is not to restrict access to
the first element, it's simply to conform to a certain API.
I think the point we're making here with T* vs ref T is that most good
work could and should be done with references that have provable
scoping. Needing the actual address of something should not be casual.
That is fine, as long as it is possible, and NOT overly-complex. Think of
it like casting. Casting is essentially a no-op for performance, but is
possible, explicit (well, *mostly* explicit), and straightforward.
I don't see the problem with restricting address-taking of ref parameters
or return values to @system code. Well, other than making it less
attractive to code in @safe mode, but then again, I don't see myself using
it much the way it is now.
Most certainly, we should not outlaw taking the address of ref parameters
because it's "hard" to solve the problem of getting property delegates
(but only as long as people insist that adding to __traits is taboo).
That was MY point. Your "solving" a problem by ignoring it, and also
causing 10 problems elsewhere.
-Steve
