Qualification::qualifier may not be sufficient

[d-winsor]

Qualification::qualifier() may not be sufficient because it doesn't handle nested qualifiers and the removal of qualifiers.

int** x;
(const int* const* const) x;

const int* y;
const_cast<int*>(y);

To solve nesting you could nest the Qualification nodes but this does not solve removal of qualifiers. Another thing to consider with this method is the expr constraint on the Nodes, would you apply 7.2.2/2 (C++ draft) to the nested Qualification Nodes?

A different solution would be to include the fully qualified target type and leave computation of what was altered up to the user.

[GabrielDosReis]

cv-qualification is a standard conversion (i.e. implicit conversion): it always adds a cv-qualifier, so I am not quite sure of exactly what removing a cv-qualifier would be here -- I expect such conversion to be explicit, not implicit, and as such represented as any of the conversation notation that are necessarily explicit.

[d-winsor]

What about the nested Qualification nodes:

• How would a nested Qualification node work. You can't just throw Qualification in the expr of the first because how would you determine what level the qualifiers apply to.
• Would you apply 7.2.2/2 (C++ draft) to the constraint of each nested Qualification Node?

[GabrielDosReis]

1. How would a nested Qualification node work. You can't just throw Qualification in the expr of the first because how would you determine what level the qualifiers apply to.

If the compiler presents you with enough information to determine that you're indeed facing a tower of qualification conversions, then build a tower of Qualification nodes in IPR [preferred]. Otherwise, you don't have that information, so you don't know, you are left with a Coercion node [least preferred]. In both cases, you build an IPR node that designates an implicit conversion.

2. Would you apply 7.2.2/2 (C++ draft) to the constraint of each nested Qualification Node?

The IPR library is not a compiler. It is a set of data structures designed to represent the intrinsic semantics of C++ programs, independently of a given compiler quirks. I expect that in all cases, the compiler has already applied that semantics constraint 7.2.2/2 so that you're not even aware of that type adjustment. In the unlikely event that a given compiler presents you explicitly with that type adjustment, I would expect a Pretend IPR node to represent that. Do we have instances of that happening? How are the nodes presented to you?

[GabrielDosReis]

Are there remaining points or issues that have not been covered?

[d-winsor]

I believe that clarifies things If the compiler wants to insert a Pretend node they can but most of the time they are likely to just apply the logic to the expression's constraint. Just out of curiosity is there any case where a Pretend node usage will be required to form a valid IPR.