Is @property implementable?

[Steven Schveighoffer]

On Wed, 02 Mar 2011 16:49:40 -0500, Michel Fortin  
<michel.fortin at michelf.com> 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