DIP26: properties defined

[Andrei Alexandrescu]

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