Fixing const arrays

[Jonathan M Davis]

On Saturday, December 10, 2011 15:47:13 Andrei Alexandrescu wrote:
> Walter and I discussed today and decided to fix this long-standing issue:
[snip]

This looks like a solid decision, and I was actually about to suggest it when 
thinking about the issues with const ranges today. It's the only sensible 
solution that I can think of. I was wondering if there might be any negative 
side effects to it, but I haven't been able to think of any.

It would be nice to do the same thing with static arrays, but that would make 
it harder to pass static arrays to templated functions, and it actually 
becomes quite dangerous, since it then becomes very easy to mistakenly return 
references to that static array when the scope is exited. So, I think that the 
issue of having to slice static arrays should probably remain, but unlike 
dynamic arrays, static arrays _do_ own their memory, so it's quite reasonably 
to have to slice them IMHO.

The other remaining issue is how to handle tail-const in the general case. 
Ideally, there would be a way to return a tail-const range from a const range. 
The only way I can think of enabling that at the moment is to make it so that 
if opSlice is defined for a type, and it returns the same type (save for how 
const or immutable it is), then it could be treated the same way as arrays 
would be as far as template instantiations go (that is, the newly suggested 
way). But I don't know quite what side-effects that has. Still, I do think that 
we should find a way to define tail-constness for ranges which are user-defined 
types. It's not as critical as with arrays, but given the transivity of const, 
it's still important, since it can be very easy to end up in a situation where 
it becomes somewhat problematic to get a tail-const range when you're using 
const much.

In any case, I applaud this decision. It should definitely help dealing with 
arrays as ranges easier. The fact that const and immutable don't work very 
well at all with ranges at this point is problematic given how const and 
immutable are supposed to be major features of the language, and this is 
definitely a step in the right direction.

- Jonathan M Davis