On Thu, 21 Apr 2011 16:14:22 -0400, Jonathan M Davis <[email protected]> wrote:

On Thu, 21 Apr 2011 15:57:57 -0400, Jonathan M Davis <[email protected]>

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.
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos

Reply via email to