On 2/9/13 5:31 AM, Jonathan M Davis wrote:
With any API that templates use, the exact syntax of the functions or
properties used must be defined. Otherwise, you're going to be screwed by
things like a templated function using parens to access a property working in
some cases and not in others (because some types defined it as a function
whereas others defined it as a property). Even worse, it _completely_ breaks
properties which return delegates. front() _must_ make the call on the return
value of front and not just call front. If front can sometimes be a function
or sometimes be a property, then the code will function drastically differently
depending on whether one or two sets of parens were used.
It's bad enough that parenless function calls are legal, but if you let a part
of your API be either a property or a function, you're asking for it. Code
_will_ break at some point because of that inconsistency. Generic just code
can't afford it. And when we're talking about something in the standard
library, it's that much more critical.
Evidence has it the other way around. We've defined plenty of fine std
ranges and algorithms before @property adorned front everywhere
(something I'm looking forward to get rid of).
Andrei
