== Quote from Michel Fortin (michel.for...@michelf.com)'s article
> Consider that currently, using an array as a range is implemented this way:
> int front(int[] array) {
> return array[0];
> }
> int[] array = [1,2,3];
> auto e = array.front;
> Currently, this work fine because the compiler treats "array.front" and
> "array.front()" as the same thing, they're both rewritten as
> "front(array)".
> Now consider the world of the future where only functions marked with
> @property can use the property syntax, and only functions *not* marked
> with @property can use the function call syntax. Now, for "array.front"
> to work you'd have to label "front" with @property, like this:
> @property int front(int[] array) {
> return array[0];
> }
> The problem is that now, for "array.front" to work it'd have to be
> rewritten as "front = array", which does not make any sense.
> So what to do? And also, what happens if you want to implement a setter
> for "array.front = 1"?
First of all, I thought that we had decided that DMD's enforcement of @property
would be loose, i.e. it should only be used to disambiguate in cases where
ambiguity exists (for example, when returning delegates). As long as there's no
ambiguity, @property should simply have no effect.
