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