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