Hmm - about manifest/enum

[Dan]

Steven Schveighoffer Wrote:

> "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.

Whether the language caters to every possible convenience need is irrelevant granted you can eventually accomplish any given program.  Const-ness is a convenience for the compiler, not a requirement to accomplish *any* given program.

In my opinion it is quite acceptable that classes are treated differently in this respect, because classes are treated differently in many other parts of D already.  They're simply inherently, internally different in enough ways that to make it seemless would be to over-abstract the language.

There are many many many cases of classes having distinct advantages or disadvantages to structs.  Let this be another.

Regards,
Dan