DIP26: properties defined

[Robert]

The DIP actually solves this.
On Sat, 2013-02-09 at 02:31 -0800, Jonathan M Davis wrote:
> I just went over this with Kenji in his thread "Partial modification
> of DIP23 
> to allow module level property." You _must_ be able to rely on front
> being a 
> property.
> 
> 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.
> 
> - Jonathan M Davis