On 2/3/13 10:16 AM, Steven Schveighoffer wrote:
> Let's go with the current proposal, and I will address the __traits
> mechanism separately.

Yes, __traits is a nice hatch if we discover we find we can't do something. Hopefully we won't find any, or just one.

Andrei

On 2/3/13 10:35 AM, TommiT wrote:
> 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;
> }

The member is chosen.

Andrei

On 2/3/13 10:48 AM, Johannes Pfau wrote:
> 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;

This introduces no contradiction. It's simple assignment to the result of fun1.

Andrei

On 2/3/13 10:49 AM, Johannes Pfau wrote:
> 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;
> }

No. That's not a lowering.

Andrei

On Sun, 03 Feb 2013 12:36:10 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 2/3/13 7:40 AM, kenji hara wrote:
>> 2013/2/3 Steven Schveighoffer <schveiguy@yahoo.com
>> <mailto:schveiguy@yahoo.com>>
>>
>>     I have a possible suggestion to fix this within your proposal:
>>
>>     @property on single-arg free functions ONLY enables a setter mode,
>>     it does not work as a UFCS getter.
>>
>>   [snip]
>>
>> I was thinking the exact same thing.
>
> Then we can't make this work:
>
> @property ref T front(T[] array) { return array[0]; }
>
> unittest
> {
>     auto a = [ 1, 2, 3];
>     auto b = a.front;
> }

ref T front(T[] array) { return array[0]; }

// same unittest

But I also can agree with the idea you currently have to make UFCS properties require a 'this' initial parameter.

-Steve

On 02/03/2013 06:47 PM, Steven Schveighoffer wrote:
> On Sun, 03 Feb 2013 12:36:10 -0500, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 2/3/13 7:40 AM, kenji hara wrote:
>>> 2013/2/3 Steven Schveighoffer <schveiguy@yahoo.com
>>> <mailto:schveiguy@yahoo.com>>
>>>
>>>     I have a possible suggestion to fix this within your proposal:
>>>
>>>     @property on single-arg free functions ONLY enables a setter mode,
>>>     it does not work as a UFCS getter.
>>>
>>>   [snip]
>>>
>>> I was thinking the exact same thing.
>>
>> Then we can't make this work:
>>
>> @property ref T front(T[] array) { return array[0]; }
>>
>> unittest
>> {
>>     auto a = [ 1, 2, 3];
>>     auto b = a.front;
>> }
>
> ref T front(T[] array) { return array[0]; }
>
> // same unittest
>

different unittest:

unittest{
    auto a = [()=>2, ()=>3, ()=>4];
    assert(a.front()==2);
}


> But I also can agree with the idea you currently have to make UFCS
> properties require a 'this' initial parameter.
>
> -Steve

On 2/3/13, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> For properties &a.prop is not the same as &(a.prop),
> which is unlike other expressions.

I have an idea. The DIP says that @property cannot return a @property function. Therefore we could introduce a new built-in property (pardon the pun) that only @property functions have, ala:

a.prop.addrOf

Similar to how we have .funcPtr for other types. This field would only exist for @propery functions and therefore it's never ambiguous on whether it applies to the function or to the function call (it *has* to apply to the function since it cannot return a @property.

So instead of having behavior based on whether there are any parens involved, you would have:

&a.prop;  // address of return value
&(a.prop)  // ditto
a.prop.addrOf  // address of property function

On Sunday, 3 February 2013 at 17:46:00 UTC, Andrei Alexandrescu wrote:
> On 2/3/13 10:35 AM, TommiT wrote:
>> 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;
>> }
>
> The member is chosen.
>
> Andrei

What happens in these examples?

Example 1:

struct S
{
    int _n;

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

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

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

--------------------------------------------

Example 2:

struct T
{
    int _n;

    @disable void opAssign(T rhs) { }
}

struct S
{
    T _t;

    @property ref T prop()
    {
        return _t;
    }
}

@property void prop(ref S s, T t)
{
    s._t._n = t._n;
}

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

On 2/3/13 1:14 PM, TommiT wrote:
> Example 1:
>
> struct S
> {
> int _n;
>
> @property ref const(int) prop() const
> {
> return _n;
> }
> }
>
> @property void prop(ref S s, int n)
> {
> s._n = 42;
> }
>
> void main()
> {
> S s;
> s.prop = 10;
> }

This is a matter of visibility. The presence of a member precludes any UFCS. Won't compile. Same for the 2nd example.

Andrei

On Sunday, 3 February 2013 at 18:28:06 UTC, Andrei Alexandrescu wrote:
> [..]
> This is a matter of visibility. The presence of a member precludes any UFCS. Won't compile. Same for the 2nd example.

Just to be perfectly clear, it must be that this wouldn't compile either, right?

struct S
{
    int _n;

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

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

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