Taking address of properties

[Robert]

On Fri, 2013-02-08 at 12:52 -0500, Steven Schveighoffer wrote:
> 
> Then it doesn't conform to the range API, where front is a property.
I can't find anything about that front has to be a property here:
http://dlang.org/phobos/std_range.html#isInputRange

all it states that you can get the current element by issuing:
	r.front
which would still be possible with the optional parentheses of DIP23.
> 
> > front for arrays would not be a property for two reasons:
> > 1. front is a UFCS function, I think supporting UFCS with properties
> is
> > just getting it wrong, have a look at DIP 23 if you don't believe
> me.
> 
> I don't believe you.  DIP23 has flaws.  Care to explain?  "just
> wrong"  
> isn't an explanation.

Look at the section "No module-level properties". Why not?! That's a
perfectly valid use of properties. The proposal disallows module-level
properties, but instead allows:
	42.fun = 43;
which reads like: assign 43 to the fun property of 42. We get this
really obscure feature but disallowing module-level properties? If that
is not wrong, than I don't know what is.
> 
> > 2. My current version, would not allow properties to return ref, but
> > instead a property is a property if it defines a getter or a setter
> or
> > both with the following exact definition:
> >
> >       @property void a(T val);
> >       @property T a();
> 
> This is a severe reduction in expression, we should not be looking
> for  
> extra ways to invalidate existing code unless there is an extremely
> good  
> reason.  "Just wrong" is not it.

I have really good reasons and I hope I'll explain them well enough in
the DIP I am currently writing. You already suggested that keeping
compatibility to a broken implementation is not worth it, simply
removing the @property in cases where there are no longer allowed, seems
not too hard a change to me, especially if we agree that we have to
break compatibility in one way or the other.