[phobos] Time to get ready for the next release

[Steve Schveighoffer]

>________________________________
>From: Robert Jacques <sandford at jhu.edu>
>To: Discuss the phobos library for D <phobos at puremagic.com>
>Sent: Thursday, April 21, 2011 4:05 PM
>Subject: Re: [phobos] Time to get ready for the next release
>
>On Thu, 21 Apr 2011 15:57:57 -0400, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
>
>>> How about the amount of existing code it breaks?  How about the fact that
>>> it breaks using the same function for both method chaining and with
>>> property syntax?
>> 
>> Something like
>> 
>> auto b = a.prop1.prop2.prop3;
>> 
>> should work. I doesn't at present, but it should. There's a bug report on it.
>
>What about auto b = a.prop1(5).prop2(6).prop3(7); ?

Looks like a poor design.  If a setter property returns anything, it should return the value set.  Otherwise:
auto b = a.prop1 = 5; // I would expect b == 5

my solution:

define a setProp1, setProp2, and setProp3 without property semantics.  It also reads better:

auto b = a.setProp1(5).setProp2(6).setProp3(7);


>> As for breaking existing code, _of course_ it's going to. That's to be
>> expected, and I would have thought that that was expected when @property was
>> introduced in the first place.
>
>Actually, no it wasn't expected. @property was introduced with loose semantics, not strict semantics. And, by the way, it was judged worth while with only loose semantics.

I don't know what messages you read, but strict properties were what was approved.  There have been numerous discussions on the NG regarding properties, some pro-strict, some pro-loose, but the one which got the deal done was pro-strict.

The loose semantics were introduced to serve as a translation period, where you could migrate property code to using @property.  From what I remember, Walter tried to turn on strict properties, but found too many errors in Phobos to deal with.  So it has been back-burnered.

Without strict properties, the author of the code cannot enforce usage semantics, and therefore, will lead to ambiguities.  The only exception I can see is calling a function with no arguments which returns void without the parentheses.  It cannot be mistaken for a property getter, because it can't be used as a getter.


-Steve