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