Hmm - about manifest/enum

[Steven Schveighoffer]

"Janice Caron" wrote
> On 12/31/07, Steven Schveighoffer wrote:
>> How about doing an in-place sort of an array of const classes?
>>
>> const(C)[] myarray;
>
> How would you even /create/ such a thing in the first place? How could
> you populate it?

Obviously if it's so difficult to imagine such a concept, then something is 
broken.  I recall from Walter's original post that if you want an array of 
const class references, you build it by appending them.  I think that 
strategy sucks.

>
> In any case, the obvious solution is to just do things a different
> way. There are plenty of alternative strategies. The most obvious one
> which springs to my mind is just to use pointers:
>
>    const(C)*[] myarray;

Remember that a const(C)* is a pointer to a reference, so now you need 
something to hold the memory that is the reference itself.  You can't just 
do myarray[x] = new C.  So you have to do 2 allocations, one to allocate the 
const class, and one to allocate the const reference to the class, which 
means your heap is holding an extra pointer when there is no need, just so 
the language spec can be 'simpler'.  I think to fill this array, it's going 
to be just as hard as filling the const(C)[] array.

>
>> // swap two items i and j
>> auto tmp = myarray[i];
>> myarray[i] = myarray[j]; // error
>> myarray[j] = tmp; // error
>
> ...and that would work now.

Fair enough, but the solution still fails because I have to use double the 
space and extra processing, and creating such an array is too complicated.

>
>
>> This
>> feature of being able to swap two references to const data is a very 
>> common
>> algorithmic requirement.
>
> Neither C nor C++ lets you do this. C doesn't even /have/ references.
> C++ has references, but they are always const. For both of these
> languages, you have to use pointers if you want to do this sort of
> thing. It's not a big deal. We can live without it.

D references ARE pointers.  The problem is that with classes, I can't change 
the constness of the class without changing the constness of the pointer 
(reference).  With C++ I can.  With D structs I can.  Tell me, why is it 
acceptable to have tail const for struct references, but not for class 
references?  There is no technical reason this can't exist.  It's not 
required for Walter's const dream to have class references always have the 
same constness as the referenced class itself.  It's not required to have 
tail-const for structs (not struct references) if you have tail-const for 
class references.  My belief is that he just can't find the right way to 
express this idea, and so instead of trying to work through it, he's given 
up.  I think he inexplicably can't unlink tail const for structs from 
tail-const for references (pointers).  In his mind, it's both or none, which 
both suck.  The right answer is: tail-const for references and pointers, no 
tail-const for structs.

And no, *we* can't live without it.  Maybe you can, but I can't.

I'm done arguing this point.  If you can't see the value in having 
tail-const for class references after all this, and the lack of a good 
reason for not having it, then there is no reason to keep trying to convince 
you.  I believe that in the end, when Walter starts trying out this new 
const, he'll find it very unwieldly and have to change it again.  I'm just 
trying to help him see that ahead of time.

-Steve