DIP26: properties defined

[Robert]

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.
On Fri, 2013-02-08 at 22:04 -0800, Jonathan M Davis wrote:
> I completely disagree with disallowing UFCS properties. Not only is
> it 
> outright required for arrays, but it's currently possible to turn
> anything 
> into a range (even types over which you have no control) simply by
> defining the 
> functions (including property functions) for it externally. And you
> could do 
> the same with most any API required by a template. If UFCS properties
> were 
> disallowed, then that would become impossible for any API which
> included 
> properties. That's unnecessarily restrictive.