DIP26: properties defined

[Jonathan M Davis]

On Saturday, February 09, 2013 12:31:14 FG wrote:
> On 2013-02-09 11:31, 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.
> 
> front getter MUST be a property... as in RFC2119's MUST??
> So all those 75 std @property ref T foo() are also here to stay for good?
> Bah, banning ref fixed some things, but now it's back to square one again.
> Maybe it's time to drop the property subject and move on? :)

You must be able to rely on front always being used without parens, and you 
must be able to rely on front() doing a call on the return value rather than 
simply calling front. Otherwise, you're going to have problems with code 
erroneously using parens to call front and breaking when used with anything 
that actually defines it as a property, and you'll break anything involving 
delegates or other callables. Returning ref is irrelevant, especially if we 
get full property rewrites (e.g. front += 7 and the like works with property 
functions without ref). What matters is that the syntax is consistent and that 
the semantics of using parens on front are consistent. Generic code needs to 
work with anything with the right API, and making front a function will cause 
problems with that.

- Jonathan M Davis