Am Fri, 25 Jan 2013 14:59:58 -0500 schrieb Andrei Alexandrescu <seewebsiteforem...@erdani.org>:
> I agree with all of the above. There has been a fair amount of > rationalization and appeal to emotion on all sides. It would be great > to get back to reason and clearly compartmentalize objective > arguments (of which there have been a few very profound ones) and > personal preference. Do that on this wiki page: http://wiki.dlang.org/Property_Discussion_Wrap-up > There's more "@property" to be seen with "save" and "back". > Subjectively that just didn't work well for me. It adds clutter to an > otherwise simple and straightforward API, and penalizes usage for > benefits that I could never reap. I think it actually makes sense. I even tried writing ranges for std.digest where front was not a property but a field and was surprised it didn't work. (isInputRange shouldn't check for property. It should check for "can be used like a field" which means field+property.). > I understand how some people are > glad to put that in everywhere, and find meaning in requiring parens > with popFront and popBack but not the others. Yet for me it was > liberating (see 1 above too) I could just write "r.popFront" without > the parens and have it do its deed. It is the right semantics for a > simple syntax. Please read the wiki page. popFront or popFront() is orthogonal to the property discussion. > > 3. Whatever we do going forward should be _simple_ but not > _simplistic_. Right now it's easy to forget that we're all close to > the subject. We have it in working memory (at least it's what I think > about all the time) and any incremental complexity is an easy cost to > absorb intellectually. > > But when we need to teach this to newcomers or even approach it again > with a "cold cache", any undue complexity will be jarring. Wiki page, wiki page ;-) > > 4. Whether we like it or not, backward compatibility is an issue. The > parens or no parens aspect upon a function call is too ubiquitous to > write off as an obscure circumstance. So I don't think the obscurity > argument applies. > > Granted, there are several ways to approach the compatibility issue, > all with their specific tradeoffs. All I'm saying is that careful > considerations of compatibility must be integral to whatever we do > about this. The approach described on the wiki does break some code, but that code shouldn't compile anyway: @property functions with wrong number of arguments and similar stuff. Only controversial thing is taking the address of a property, but I can't think of a solution which would work well with generic code so I'd just say forbid that. > > 5. This is a matter in which reasonable people may disagree. For > better or worse Walter and to a lesser extent myself are in the > position to decide. We're doing the best to gather, mind, and > integrate opinions and suggestions but clearly no decision that would > please everyone. Would be nice if the arguments for the final decision are added to the wiki page :-)