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).
