Fixing const arrays

[Jonathan M Davis]

On Sunday, December 11, 2011 02:05:08 Andrei Alexandrescu wrote:
> On 12/11/11 1:30 AM, Jonathan M Davis wrote:
> > On Sunday, December 11, 2011 01:16:28 Andrei Alexandrescu wrote:
> >> To truly confer user-defined types the same capability, we should
> >> define
> >> opPassByValue() which is implicitly invoked whenever an object is
> >> passed
> >> by value into a function. By default that is a do-nothing operator;
> >> for
> >> arrays it would do the cast thing (or, equivalently, invoke "[]" on
> >> the
> >> array), and people could define it to do whatever. We could do all
> >> that.
> >> The question is, is the added complexity justified?
> > 
> > I think that it's completely justified. We need a way to define
> > tail-constness for ranges. Given const's transitiveness, it's very easy
> > to end up in a situation where you have a const range, and having a
> > means to get a tail-const version of that range would be very valuable.
> > I don't know if opPassByValue is the best solution, but if not, we at
> > least need a similar one.
> 
> I'm not sure. How many times have you been in a place in life where you
> had a const range on your hands, that's not an array? I haven't.

I tend to avoid const ranges precisely because they pretty much never work. 
I'd use them more if a tail-const version of them were easily obtainable - 
_especially_ if they worked the same way that arrays are going to be working 
with IFTI. Also, as std.container is filled out, the number of ranges which 
aren't arrays will definitely increase. Right now, they're almost always arrays 
or arrays wrapped by other ranges, and often you have to call array on the 
wrapped ones anyway, so a large portion of the time at this point, ranges are 
arrays. And while that will still hold to some extent, that should lessen as 
std.container is fleshed out. And that means that issues with const ranges will 
increase.

Also, it's completely inconsistent that you can pass a const array to a range-
based function and have it work but not a const user-defined range. It may be 
that we could get the compiler to figure it out based on slicing (assuming that 
opSlice returns the same type as the range itself aside from constness - 
otherwise passing containers to range-based functions would instantiate on the 
containers, which would cause issues, especially since it would be the 
container being passed, not a slice). And if we could do that, then I don't 
think that there would be any need for opPassByValue, but without a solution 
along those lines, we're going to have people complaining about not being able 
to pass const value-type ranges to range-based functions. And as fantastic as 
template constraints are, they don't make it immediately obvious why the type 
failed - certainly nothing as nice as "Error: find does not work with a const 
range."

I do think that there is merit in seeing whether we can get the compiler to 
use opSlice to do what opPassByValue would do, but I also think that we should 
do something about this issue, or const ranges will forever be a problem. The 
only reasons that I don't run into the issue more is because I avoid const 
with ranges and with such a sparse std.container, so many ranges are arrays.

- Jonathan M Davis