Inability to dup/~ for const arrays of class objects

[Michel Fortin]

On 2013-05-29 16:02:58 +0000, "Daniel Murphy" <yebblies at nospamgmail.com> said:

> Introduce *C (syntax not important) to give you the raw class type, 
> much like the raw function type.  You can then apply const directly to 
> this type, and an appropriate suffix gets you back to the reference.

Are you sure you're not starting from the wrong assumption? There's no 
such thing as a "raw class type" in the compiler that is separate from 
a "class reference".

> This should reduce the compiler changes required, as I recall much of 
> the complexity was due to changing the meaning of the existing type.

To implement what you want you'd have to separate the current class 
type in two types… which would change pretty much everything related to 
classes in the compiler.

My technique for "const(Object)ref" was to minimize those changes. What 
I ended up adding is a way for a type to have head modifiers different 
from its regular modifiers (but only classes are allowed to have 
different head modifiers). Then I went on a hunt for places checking 
modifiers in the compiler (code such as `c->mod`) and convert them to 
use head modifiers instead (`c->head()->mod`) where it made sense. It 
took some time, but it's not really difficult once you figure it out.

> This would also play better with template argument deduction, as there 
> was no clear way to define it when ref was optional. The inconsistent 
> handling of arrays and pointers has since been fixed (eg const(T*) 
> matching const(U*), U becomes const(T)* and the same for arrays) so 
> there is a clear pattern to follow.

What was problematic for template argument deduction was the lack of a 
coherent example of how it should work -- which as you said has been 
fixed since -- not the optionality of ref.


-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca/