DIP26: properties defined

[Jonathan M Davis]

On Saturday, February 09, 2013 10:45:13 Robert wrote:
> I am claiming that if we restrict ourselves to the property concept
> explained in the DIP, then the range API would no longer depend on front
> being a property, it can also be a function returning ref, which is
> perfectly legal for UFCS.
> 
> I am further claiming that properties via get/set methods don't actually
> make sense outside of the entity that define them, I am glad if you
> could give an actual example that would prove me wrong.
> 
> And because properties are treated (apart from allowing = to call the
> set method) exactly like normal functions, you should note no
> difference.
> 
> It feels to me, that most problems arise due to the fact that we try to
> make properties like fields (forbidding parentheses), which make them
> essentially incompatible to functions, resulting in making all sorts of
> things properties, which actually aren't, just so that no template
> breaks.
> 
> Maybe I should make this more clear in the DIP.

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