DIP23 draft: Fixing properties redux

Steven Schveighoffer schveiguy at yahoo.com
Sun Feb 3 07:16:32 PST 2013


On Sun, 03 Feb 2013 08:00:32 -0500, kenji hara <k.hara.pg at gmail.com> wrote:

> 2013/2/3 Steven Schveighoffer <schveiguy at yahoo.com>
>
>> On Sun, 03 Feb 2013 07:16:17 -0500, Steven Schveighoffer <
>> schveiguy at yahoo.com> wrote:
>>
>>  On Sun, 03 Feb 2013 03:16:08 -0500, Andrei Alexandrescu <
>>> SeeWebsiteForEmail at erdani.org**> wrote:
>>>
>>>  Walter and I have had a discussion on how to finalize properties.
>>>>
>>>> http://wiki.dlang.org/DIP23
>>>>
>>>
>>> I agree with everything in this.  This looks exactly like what I  
>>> wanted a
>>> few days ago.  Thank you!
>>>
>>> One aspect not addressed is free-function properties:
>>>
>>
>> I thought of one other problem with this proposal.  You can no longer  
>> get
>> a delegate of a property.  Like it or not, there will be existing code  
>> that
>> does get a delegate to properties (it is allowed now).
>>
>> I think we should provide a __traits accessor for this.  Otherwise,  
>> there
>> is no way to port said code to the new style.
>>
>
> On the contrary with you, I was read that we no longer get an address of
> ref returned value by address-op.
>
> @property ref int foo();
> static assert(is(typeof(&foo) == ref int function()));  // typeof does  
> not
> return int*
>
> If I am correct, there is no need for special enhancement like __traits.

You are right, it does not specify this, I was somewhat mistaken.

But the spirit of the proposal seems to suggest that for all intents and  
purposes, a property's type is the type of it's return value.

For the most part, taking the address of an rvalue is an error anyway, so  
it makes sense to make this type of function return a delegate with the &  
operator.

However, in the case of ref returns for properties, I think it may be too  
limiting if it is impossible to get the address of a ref return:

@property ref int foo();

int *x = &foo;  // error returns delegate?
int *y = &foo(); // error, using parens illegal?

Somewhat glaring here is that you can't make ref local variables.

I suppose in this case, the such a function could have @property removed  
on it, but that is little help to the user of such a function who has no  
control over the API.

A potential workaround could be a la Timon's suggestion:

ref int foowrap() { return foo;}
int *x = &foowrap();

Let's go with the current proposal, and I will address the __traits  
mechanism separately.

-Steve


More information about the Digitalmars-d mailing list