Open xmh0511 opened 3 years ago
First of all, [conv.qual] p1 clearly says that a qualification-decomposition with n=0 for a type T does exist, and simply is cv U. No P exists for that case, so the "if" in p3.2 is vacuously false: "if P is array of unknown bound" is false because there is no P, so it can't possibly be "array of unknown bound".
A conversion from int
to const volatile int
should be a qualification conversion. It is under [conv.qual], but as you noticed, it is also an integral conversion, which is wrong and needs to be fixed.
For class types, we should simply use "similar" instead of "same" class type.
In [dcl.init.ref] p4, the "reference-related" is defined as
Consider this example
Presumably, it is restricted by [dcl.init.ref#5.4.4]
Is the type
int
similar toint
? It should be determined by [conv.qual] p2However, the qualification-decomposition of type
int
does not have any Pi component. Maybe, one could argue since they are empty, they're the same.From a prvalue of type
int
to typeint
, or from a prvalue of typeint
toint const volatile
, Is it a qualified conversion? It seems [conv.qual] p3 can apply to these two conversions except that whether [conv.qual#3.2] is suitable for empty Pi, however, we can also say it's [conv.integral]Maybe, we should give this conversion accurate meaning.
For class type, it is a bit different, since a prvalue of cv class type can retain the cv-qualification. So, assume
T
is a class type, from a prvalue of typevolatile const T
to typeT
is a user-defined conversion? Why I say it is a user-defined conversion because of [over.best.ics#general-6] and [over.ics.user]Since
T
andvolatile const T
are not the same type, hence the conversion is user-defined conversion?Obviously,
#1
and#4
are called. Maybe we should fix [over.best.ics#general-6] and [over.ics.user] to thatThese issues arise from the permitted types.