Taking address of properties

Steven Schveighoffer schveiguy at yahoo.com
Thu Feb 7 13:07:08 PST 2013


On Thu, 07 Feb 2013 15:14:22 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 2/7/13 2:13 PM, Steven Schveighoffer wrote:
>> On Thu, 07 Feb 2013 13:05:50 -0500, Robert <jfanatiker at gmx.at> 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


More information about the Digitalmars-d mailing list