February 28, 2013
Possibly setters had better have 'void' as their return type.
Then
    auto a = b.setter = 3;
will have the predictable behavior with both 'a' and 'whatever b-setter sets' being set to 3. Otherwise, it might be totally unpredictable.

On the other hand, possibly setters MUST return a value of the same type they accept, in order to be able to emulate standard-like behavior.

When I re-read it, the 1-st option looks cleaner.
February 28, 2013
On 02/28/13 14:33, angel wrote:
> Possibly setters had better have 'void' as their return type.
> Then
>     auto a = b.setter = 3;
> will have the predictable behavior with both 'a' and 'whatever b-setter sets' being set to 3. Otherwise, it might be totally unpredictable.
> 
> On the other hand, possibly setters MUST return a value of the same type they accept, in order to be able to emulate standard-like behavior.
> 
> When I re-read it, the 1-st option looks cleaner.

    ...
       long setter(long v) @property;
    ...
    auto a = b.setter = 3;

    // and there's no reason to disallow:
    long setter(ubyte v) @property;
    long setter(T:long)(T v) @property;
    long setter(U)(U v) @property;
    // etc

artur
February 28, 2013
On Thursday, 28 February 2013 at 13:06:39 UTC, Jacob Carlborg wrote:
> On 2013-02-28 09:21, deadalnix wrote:
>
>> Must is not appropriate here, as it isn't an obligation at all. I don't
>> really see what is the concern here.
>>
>> If the function is simple, then it will be inlined and unused returned
>> values can be optimized away. If the function is complex, the cost of
>> returning something when not needed will be negligible anyway.
>>
>> What is your concern here ?
>
> My concern here is setters that doesn't return a value. They won't work with chained assignments. Another thing that will break when changing a filed to a property.

That is up to the writer of the setter. Note that you can also create getter that returns void. It is even more stupid. As long as it isn't error prone.
February 28, 2013
On 2013-02-28 15:45, deadalnix wrote:

> That is up to the writer of the setter. Note that you can also create
> getter that returns void. It is even more stupid. As long as it isn't
> error prone.

I think that's not a property by definition.

-- 
/Jacob Carlborg
February 28, 2013
There _is_ reason.
You may, possibly, argue this reason is not important enough - here you might be right or wrong, I don't know.
The point is a @property should behave as close as possible to a real variable:

class A {
    int field;
}
auto a = new A();
auto x = a.field = 3;

Now you 'upgrade' 'field' to a @property

class A {
    int _field;
    @property ??? field(int val) {
        _field = val;
    }
}
auto a = new A();
auto x = a.field = 3;
The above line should behave _identically_ to the previous case.
Will it, if you define "@property char field(int val)" ? Apparently no.
March 01, 2013
On Thursday, 28 February 2013 at 14:55:06 UTC, angel wrote:
> There _is_ reason.
> You may, possibly, argue this reason is not important enough - here you might be right or wrong, I don't know.
> The point is a @property should behave as close as possible to a real variable:
>
> class A {
>     int field;
> }
> auto a = new A();
> auto x = a.field = 3;
>
> Now you 'upgrade' 'field' to a @property
>
> class A {
>     int _field;
>     @property ??? field(int val) {
>         _field = val;

return _field = val;

>     }
> }
> auto a = new A();
> auto x = a.field = 3;
> The above line should behave _identically_ to the previous case.
> Will it, if you define "@property char field(int val)" ? Apparently no.

The current proposal is simpler and allow more. It surely does allow to do crazy stupid things, but you can't really allow more without allowing to do dumb things.
March 02, 2013
On 02/27/2013 04:46 PM, deadalnix wrote:
> Here come the sister of DIP27 : DIP28 http://wiki.dlang.org/DIP28 .
>
> It address specifically properties. A 3rd one is coming on delegate. As
> for DIP27, the goal is to go aggressively for simplicity.

Ignoring complexities and complications is not called simplicity, it's simplism.

DIP27 s a simplistic subset of DIP24.
March 02, 2013
On Saturday, 2 March 2013 at 16:00:55 UTC, Timon Gehr wrote:
> On 02/27/2013 04:46 PM, deadalnix wrote:
>> Here come the sister of DIP27 : DIP28 http://wiki.dlang.org/DIP28 .
>>
>> It address specifically properties. A 3rd one is coming on delegate. As
>> for DIP27, the goal is to go aggressively for simplicity.
>
> Ignoring complexities and complications is not called simplicity, it's simplism.
>
> DIP27 s a simplistic subset of DIP24.

It be simplism if reduced the expressiveness of the language. It doesn't.
March 02, 2013
On Saturday, 2 March 2013 at 16:00:55 UTC, Timon Gehr wrote:
> On 02/27/2013 04:46 PM, deadalnix wrote:
>> Here come the sister of DIP27 : DIP28 http://wiki.dlang.org/DIP28 .
>>
>> It address specifically properties. A 3rd one is coming on delegate. As
>> for DIP27, the goal is to go aggressively for simplicity.
>
> Ignoring complexities and complications is not called simplicity, it's simplism.
>
> DIP27 s a simplistic subset of DIP24.

DIP24 and DIP28 are very similar in regard of property, that is exact. (As it is in DIP28 topic, I assume that you meant DIP28).

Main difference I see :
 - Introduction of __traits(propertyAccessors, propertySymbol) . This is loosely correlated to the content of each DIP. Both can do with or without.
 - typeof(__traits(propertyAccessors, prop)(exp)) is void and its result is used. I don't see the point of special casing this. It increase complexity and reduces what you can express.

It is unclear what happen when the property is aliased or passed as alias parameter in both DIP, and should be effectively corrected.
March 02, 2013
On 03/02/2013 05:22 PM, deadalnix wrote:
> On Saturday, 2 March 2013 at 16:00:55 UTC, Timon Gehr wrote:
>> On 02/27/2013 04:46 PM, deadalnix wrote:
>>> Here come the sister of DIP27 : DIP28 http://wiki.dlang.org/DIP28 .
>>>
>>> It address specifically properties. A 3rd one is coming on delegate. As
>>> for DIP27, the goal is to go aggressively for simplicity.
>>
>> Ignoring complexities and complications is not called simplicity, it's
>> simplism.
>>
>> DIP27 s a simplistic subset of DIP24.
>
> DIP24 and DIP28 are very similar in regard of property, that is exact.
> (As it is in DIP28 topic, I assume that you meant DIP28).
>
> Main difference I see :
>   - Introduction of __traits(propertyAccessors, propertySymbol) . This
> is loosely correlated to the content of each DIP. Both can do with or
> without.

Agreed.

>   - typeof(__traits(propertyAccessors, prop)(exp)) is void and its
> result is used. I don't see the point of special casing this.

Consistent support for multiple assignment.

> It increase complexity

Yup, marginally.

> and reduces what you can express.
>

Not strictly.

> It is unclear what happen when the property is aliased or passed as
> alias parameter in both DIP, and should be effectively corrected.

No, both DIPs specify it exactly. DIP28 is broken in that regard.
But DIP28 leaves it up to imagination what it means for an expression to occur in the left-hand side of an assignment.