[phobos] Time to get ready for the next release

[Robert Jacques]

On Thu, 21 Apr 2011 16:14:22 -0400, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

>> 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); ?
>
> I'd consider that to be the same. It should work, but it doesn't.  
> There's a
> bug report for it.

Ahem, so you'd consider auto b = a.prop1(7); valid code under strict  
property rules?

>> > 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.
>
> Virtually every discussion I recall about @property has indicated that we
> expected to have strict semantics eventually. It's been long enough,  
> that I
> don't remember all of the discussions about @property when it was  
> intially
> introduced, but I believe any discussion of @property that's happened at  
> all
> recently and discussed enforcement expected there to be strict semantics
> eventually. And there have been several confused newbies posting about  
> how
> @property wasn't enforced.

And virtually every discussion you've every had has been with/inside a  
pro-properties members on D (which happens with many new feature  
discussions). When the @property group finally got some traction with  
Walter/Andrei (with the zero-argument delegate use case), it was asked if  
method-as-properties was slated for eventual removal (i.e. if @property  
was to be strict), and Walter responded that method-as-properties wasn't  
going to be removed.

I'm feeling like there might be some miscommunication here. A function  
tagged @property would behave identically under both 'loose' and 'strict'  
semantics. The difference is the 'loose' semantics implies that  
method-as-properties also exists. 'strict' semantics removes the  
method-as-properties feature from the language.