Fixing const arrays

[Jonathan M Davis]

On Tuesday, December 13, 2011 21:36:43 Michel Fortin wrote:
> 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.

I'd think that some revision would be possible even if it breaks code as long 
as there is great need for it - though that would depend on Walter's decision. 
But since @property is in TDPL, a complete redesign wouldn't make sense 
without _major_ need. Smaller tweaks wouldn't be as big a deal though. I'm not 
quite sure how @property would be adjusted for some of these corner cases 
though. The basic idea works well for member functions, but once you add free 
functions into the mix, it gets more complicated.

- Jonathan M Davis