Fixing const arrays

[Andrei Alexandrescu]

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?

> Also seems strange to me that class references aren't included in that
> list, but then I though about how tail-const still doesn't work with
> objects. You'd need my const(Object)ref patch to make that work, and
> Walter hasn't taken time to look at it yet…

Have you continued to use your fork in daily work? If so, how does it 
pan out?


Andrei