Inability to dup/~ for const arrays of class objects

Daniel Murphy yebblies at nospamgmail.com
Tue Jun 11 16:24:56 PDT 2013


"Michel Fortin" <michel.fortin at michelf.ca> wrote in message 
news:ko5dl5$b2v$1 at digitalmars.com...
> 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".
>

I know, this would be an addition.

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

Yes, my hope is that this is less disruptive than changing 'everything 
related to modifiers' as your patch did.

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

I am familiar with your implementation.

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

This is not true.

What does const(C) matching (T : const(U), U) give?

If we follow what arrays and pointers do, it removes one level of const, 
giving:
const(C) : const(U)
U == const(C)ref

If you then match with (T : const(U)ref, U)

You get the 'ref' suffix removed, giving const(C), then one level of const 
removed, giving:
const(C)ref

This is the problem I hit with template deduction.  It is possible to define 
the matching differently for classes... but the problem comes from the 'ref' 
suffix being optional.

My observation is that class head types behave similar to function types - 
you can point to them but cannot instantiate them.  My hope is that most of 
the class stuff will stay in TypeClass, with a the new reference type 
leveraging the existing default treatment of TypeNext derived types.

I guess we'll see if I ever get some time to implement this. 




More information about the Digitalmars-d mailing list