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?<br><br><div class="gmail_quote">On Thu, Apr 21, 2011 at 3:39 PM, Jonathan M Davis <span dir="ltr"><<a href="mailto:jmdavisProg@gmx.com">jmdavisProg@gmx.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div></div><div class="h5">> On Thu, 21 Apr 2011 13:45:09 -0400, Jonathan M Davis <<a href="mailto:jmdavisProg@gmx.com">jmdavisProg@gmx.com</a>><br>

><br>
> wrote:<br>
> >> As I've said before, we really need to decide whether @property has<br>
> >> loose<br>
> >> or strict semantics. Loose semantics means that non-@property functions<br>
> >> would still be callable without (), etc but @property functions wouldn't<br>
> >> be allowed to have ()s. Frankly, I hate @property, want to to have as<br>
> >> little effect as possible, like the flexibility of being able to call<br>
> >> the<br>
> >> same function both ways, and would have a lot of code break if this were<br>
> >> taken away, so my vote is loose semantics.<br>
> ><br>
> > TDPL specifically gives it strict semantics. @property functions must be<br>
> > called without parens, and non-@property functions must be called with<br>
> > them.<br>
> > So, if we want to go with loose semantics, then TDPL will need to be<br>
> > changed.<br>
> ><br>
> > Personally, I don't see much point to @property if its semantics are<br>
> > loose.<br>
> ><br>
> > - Jonathan M Davis<br>
><br>
> The point of @property, and the reason it was included in the language at<br>
> all, was to provide property syntax to the corner case of a returning a<br>
> zero-argument delegate from a function. That's all. That was the only<br>
> argument which was considered strong enough out of the many forum<br>
> discussions to warrant language status. Furthermore, @property was<br>
> explicitly defined at the time as having loose semantics. Regarding TDPL,<br>
> Andrei has expressed serious concerns with going whole-hog @property since<br>
> getting more experience with actually using it, so I don't feel that TDPL<br>
> is a strong guideline.<br>
><br>
> My point is that a strict interpretation of @property has not seriously<br>
> been discussed in the D community, and that any decision made here needs<br>
> to be elevated to the D newsgroup before implementation.<br>
><br>
> My position comes down on the side of loose semantics with no method of<br>
> strict enforcement, optional or otherwise.<br>
<br>
</div></div>I know that there are a number of people on the list - particularly newer<br>
posters - who fully expect @property to be strict and are surpised when it<br>
isn't. And I see _zero_ problem with strong property enforcement as long as<br>
the compiler isn't buggy with regards to properties (which it currently is).<br>
So, I'm 100% behind strict enforcement.<br>
<font color="#888888"><br>
- Jonathan M Davis<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
phobos mailing list<br>
<a href="mailto:phobos@puremagic.com">phobos@puremagic.com</a><br>
<a href="http://lists.puremagic.com/mailman/listinfo/phobos" target="_blank">http://lists.puremagic.com/mailman/listinfo/phobos</a><br>
</div></div></blockquote></div><br>