On Sun, 03 Feb 2013 08:04:10 -0500, Timon Gehr <timon.gehr@gmx.ch> wrote:

> T delegate() f = &a.prop -> auto f = ()=>a.prop;
> T delegate(T) f = &a.prop -> auto f = (T x)=>a.prop=x;

I don't like this solution.  You are creating a dummy delegate function, and moving the stack frame into the heap, just so you can get a delegate to an already existing function.

-Steve

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

> 2013/2/3 Steven Schveighoffer <schveiguy@yahoo.com>
>
>> On Sun, 03 Feb 2013 07:16:17 -0500, Steven Schveighoffer <
>> schveiguy@yahoo.com> wrote:
>>
>>  On Sun, 03 Feb 2013 03:16:08 -0500, Andrei Alexandrescu <
>>> SeeWebsiteForEmail@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

On 02/03/2013 04:04 PM, Steven Schveighoffer wrote:
> On Sun, 03 Feb 2013 08:04:10 -0500, Timon Gehr <timon.gehr@gmx.ch> wrote:
>
>> T delegate() f = &a.prop -> auto f = ()=>a.prop;
>> T delegate(T) f = &a.prop -> auto f = (T x)=>a.prop=x;
>
> I don't like this solution.  You are creating a dummy delegate function,
> and moving the stack frame into the heap, just so you can get a delegate
> to an already existing function.
>
> -Steve

The spec could be updated to allow/mandate eta-reduction where applicable.

On Sunday, 3 February 2013 at 15:04:15 UTC, Steven Schveighoffer wrote:
> On Sun, 03 Feb 2013 08:04:10 -0500, Timon Gehr <timon.gehr@gmx.ch> wrote:
>
>> T delegate() f = &a.prop -> auto f = ()=>a.prop;
>> T delegate(T) f = &a.prop -> auto f = (T x)=>a.prop=x;
>
> I don't like this solution.  You are creating a dummy delegate function, and moving the stack frame into the heap, just so you can get a delegate to an already existing function.
>
> -Steve

Unless you escape the delegate, it should allocate on the heap. And any inlining compiler should remove the delegate completely anyway.

On Sunday, 3 February 2013 at 15:16:30 UTC, Steven Schveighoffer wrote:
> 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.
>

If you want a function, then just don't annotate with @property. The whole point of property is that it doesn't behave like a function.

On Sunday, 3 February 2013 at 08:16:08 UTC, Andrei Alexandrescu wrote:
> Walter and I have had a discussion on how to finalize properties.
>
> http://wiki.dlang.org/DIP23
> [..]

What happens here?

struct S
{
    int _n;

    @property ref int prop()
    {
        return _n;
    }
}

@property void prop(ref S s, int n)
{
    s._n = 42;
}

void main()
{
    S s;
    s.prop = 10;
}

On 2/3/13 7:34 AM, Jacob Carlborg wrote:
> On 2013-02-03 09:16, Andrei Alexandrescu wrote:
>> Walter and I have had a discussion on how to finalize properties.
>>
>> http://wiki.dlang.org/DIP23
>
> What about:
>
> writeln = "asd";
>
> Allowed or not?

No because writeln is not a property. For non-properties there's no lowering of assignment.

Andrei

Am Sun, 03 Feb 2013 04:40:44 -0800
schrieb Jonathan M Davis <jmdavisProg@gmx.com>:

> On Sunday, February 03, 2013 13:34:14 Jacob Carlborg wrote:
> > On 2013-02-03 09:16, Andrei Alexandrescu wrote:
> > > Walter and I have had a discussion on how to finalize properties.
> > > 
> > > http://wiki.dlang.org/DIP23
> > 
> > What about:
> > 
> > writeln = "asd";
> > 
> > Allowed or not?
> 
> I take it that you didn't read the DIP. At the very beginning of its section on "Write properties:"
> 
> -----------
> In order to use the assignment operator "=" property-style, the @property annotation MUST be used.
> -----------

There's a example on the page though which contradicts this:

static int x;
ref int fun1() { return x; }
fun1 = 42;

Am Sun, 03 Feb 2013 10:37:45 -0500
schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:

> On 2/3/13 7:34 AM, Jacob Carlborg wrote:
> > On 2013-02-03 09:16, Andrei Alexandrescu wrote:
> >> Walter and I have had a discussion on how to finalize properties.
> >>
> >> http://wiki.dlang.org/DIP23
> >
> > What about:
> >
> > writeln = "asd";
> >
> > Allowed or not?
> 
> No because writeln is not a property. For non-properties there's no lowering of assignment.
> 
> Andrei
> 

Then this should be removed in the proposal:

If a function returns a reference, then assignment through the paren-less call should work:

unittest
{
    static int x;
    ref int fun1() { return x; }
    fun1 = 42;
}

2013/2/4 Steven Schveighoffer <schveiguy@yahoo.com>

> On Sun, 03 Feb 2013 08:00:32 -0500, kenji hara <k.hara.pg@gmail.com> wrote:
>
>> 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.
>
[snip]

It is already satisfied. Inside typeof, all use of property makes its
return type.
I think the case of getting address of ref value returned from a property
is much rare.

If you really want to do it, we can write short workaround.

A potential workaround could be a la Timon's suggestion:
>
> ref int foowrap() { return foo;}
> int *x = &foowrap();
>

One liner version:

int* x = ((ref x) => &x)(foo);

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

It seems to me that is an overkill.

Kenji Hara