Fixing const arrays

[Jonathan M Davis]

On Sunday, December 11, 2011 01:16:28 Andrei Alexandrescu wrote:
> On 12/10/11 5:20 PM, Michel Fortin wrote:
> > On 2011-12-10 21:47:13 +0000, Andrei Alexandrescu
> > 
> > <SeeWebsiteForEmail at erdani.org> said:
> >> We decided to fix this issue by automatically shedding the top-level
> >> const when passing an array or a pointer by value into a function.
> > 
> > It seems strange that if you implemented the exact same semantic as an a
> > dynamic array or a pointer with a struct it wouldn't work. Basically,
> > you're making a special case by giving two language-defined types
> > characteristics that can't be replicated by user types. I'm not
> > concerned that much, but I thought you worried about those things
> > Andrei.
> 
> I do worry about those things, and this decision comes at the end of a
> long deliberation.
> 
> There would be several aspects to discuss here. First, you are right
> that this confers built-in arrays a property that's not reproducible to
> user-defined types. And that's a bad thing.
> 
> Second, that's not really as bad because the real issue is elsewhere.
> Remember the type "new T[]"? That was supposed to be the array type,
> which was to be supplanted by its range type, "T[]". After
> experimentation we decided to give up on that. Why? Because its benefits
> didn't justify the complication.
> 
> So the issue we're solving here is that arrays and the ranges that crawl
> on them are represented by the same type. User-defined types have the
> option of defining distinct types for that.
> 
> 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'd say that in general, with opPassByValue, in the worst case, some people 
don't use it for their range types and those ranges don't work properly in 
cases that require tail-const. But those people who _do_ use it can benefit 
from it. It doesn't force anything on anyone. Yes, it's one more thing to 
learn about know about in D, but it _is_ something that a number of us have 
cited a need for for a while.

- Jonathan M Davis