How to correctly handle immutable ranges

[monarch_dodra]

On Monday, 31 December 2012 at 13:31:44 UTC, Peter Alexander 
wrote:
> My questions are:
>
> 1. First, why is top-level immutable stripped for arrays and 
> pointers but not other types?
> 2. How should you handle the special case of ranges of 
> immutable arrays in a consistent manner?
> 3. How should you handle the alternate iteration method with 
> opIndex/length/opSlice?
>
> Cheers,
> Peter

1. I'd say: Just because it can: If you pass in "immutable(T[])", 
then it is 100% safe to declare that that copy is a 
"immutable(T)[]". Ditto for pointers.

The same can't be said about ranges: a "immutable(Range!T)" might 
not safely copyable as a "Range!(immutable(T))"

2. I *might* start by providing "??? opSlice(void) const", which, 
when present, would allow extracting a "Range!(immutable(T))" 
from a "immutable(T)[]". It wouldn't help *much*, so no generic 
code could exploit this (as it wouldn't be required).

3. No idea.

--------
That said, some might question  the entire concept of an 
"immutable range". a "range of immutables" makes sense, the other 
way around: less so (IMO).

As for the special case of RoIR: If the top level R exposes its 
elements by ref, then it would be just plain wrong to strip the 
immutability of the underlying ranges. You could only legally 
iterate on *copies* of the subranges, but not the ranges 
themselves. This just brings us back to the problem of top level 
Immutable Ranges: IMO, RoIR is not really a special case compared 
to simple IR (outside of the slice of slice case, I guess).