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
