On Friday, August 12, 2011 16:04 Adam Ruppe wrote: > Jonathan M Davis wrote: > > const(T)[] maybe, > > but as soon as you use in, you can't use any range functions. > > That is, to me, the biggest problem with range functions and > something that should be fixed. > > There's no defense for it aside from being the status quo. It's just a > shortcoming of the current implementation, not a principled limitation.
If it can be fixed so that a slice of a const/immutable range is tail-const, then they'll be in the same boat as static arrays and at least be usable with range-based functions when you slice them, but at this point, the only way to make it so that you could simply pass them without slicing them is if you overloaded _every_ range-based functions on arrays. And since you're going to have to slice containers to pass them to range-based functions anyway (dynamic arrays are actually kind of weird in that they can be passed directly to range-based functions without slicing them - it's just that they're the most common used of ranges and therefore what we're most used to). So, I don't think that it's unreasonable to require that static arrays and const or immutable dynamic arrays be sliced to be used with range-based functions. But until it's fixed so that slices of a dynamic range are tail-const/tail- immutable instead of exactly the same type, that doesn't work with const or immutable dynamic arrays, which definitely sucks. But if that can be fixed, I think that the situation will then be fairly reasonable. - Jonathan M Davis