Inability to dup/~ for const arrays of class objects

Daniel Murphy yebblies at nospamgmail.com
Wed May 29 09:02:58 PDT 2013


"Michel Fortin" <michel.fortin at michelf.ca> wrote in message 
news:ko3ri4$kkb$1 at digitalmars.com...
>>
>> Michel Fortin has created a pull request to make
>>
>> const(T)ref
>>
>> work, and only apply the const to the data.  It's certainly doable.  But 
>> the syntax, as you can see, is ugly.
>
> Well, that pull request wasn't trivial to implement correctly and the 
> syntax took some time to come with. And also there's no guaranty Walter 
> would have accepted the somewhat contorted solution even though it was 
> working pretty well (but with no review comment it's hard to say).
>

Manu and I had a conversation about this on the last night of dconf, a came 
up with a slight improvement -

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.  (eg 
shared(const(*C) ref) )  No more optional suffix, no more need to collapse 
chains of 'ref' back into a single type.

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

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.

In terms of syntax, I'm leaning towards asterix for prefix and postfix, ie
shared(const(*C)*) 




More information about the Digitalmars-d mailing list