On Wed, 02 Mar 2011 16:49:40 -0500, Michel Fortin
<[email protected]> wrote:
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"?
I brought this up a while ago, look for "Uniform Function Call syntax for
properties"
possible solution?
int front(@property int[] array)
Ugly, but it may make things unambiguous. Probably would have to require
this for all properties on arrays, even the unambiguous cases.
This is really the only ambiguous case. These should be unambiguous:
@property int[] front();
@property void front(int[] array, int value);
Although I don't like it, I think Jonathan's solution (just disable
settable properties in the global space) makes things the least painless.
Yes, you lose settable properties from modules, static class/struct
namespace, but it's just sugar. I think we can probably live without it.
I agree with Jonathan that most of the properties in D are members of
classes/structs.
-Steve
