Fixing const arrays

[Michel Fortin]

On 2011-12-13 23:08:43 +0000, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> We could have inferred property intention from the code pattern, 
> without requiring any keyword. That solution (which was discussed and 
> rejected in this newsgroup) was miles ahead from the drivel of 
> @property we have now.

By "code patterns", you mean something like this?

	struct Foo
	{
		int getBar();
		void setBar(int);
	}

	void main()
	{
		Foo foo;
		int a = foo.bar;  // calls getBar()
		foo.bar = a;      // calls setBar(a)
	}

I agree it's better. For one thing it'd be much less confusing about 
whether it make sense to make something a property or not because you'd 
have to write "get" in front of it -- for instance getSave doesn't make 
any sense.

And it'd be much less problematic too: the way @property is currently 
designed, you can't distinguish between a definition for a an 
array-member property getter and a module-level property setter. Also 
with the current design you have no way to disambiguate array-member 
properties with the same name coming from different modules -- can't 
replace array.front with std.range.front(array) when @property is 
enforced -- having access to the @property's underlying function would 
mitigate this -- std.range.getFront(array) would still work. The above 
code pattern would also make it saner to take the address of the getter 
function as a separate thing from taking the address of a ref value 
obtained from a property.

Personally, I'm skeptical the current property design can work as 
intended without introducing many issues like the above. I think 
perhaps the biggest mistake was to not implement it fully from the 
start at a time where we could easily revert to another proposition if 
it proved to be problematic. Unfortunately, now we're stuck with 
@property and all its problems… although I'd sure like the design to be 
revised.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/