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