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.
