[expr.const.cast] Use "shall" to impose the requirement CWG2828

[xmh0511]

[expr.const.cast] p3 states

For two similar types T1 and T2, a prvalue of type T1 may be explicitly converted to the type T2 using a const_­cast if, considering the qualification-decompositions of both types, each P¹_i is the same as P² _i for all i. The result of a const_­cast refers to the original entity.

Presumably, the requirement in this rule should impose on any case that uses the const_cast casting. Even though the conversion would be a standard qualification conversion, it is not supported

typedef int CK[][2];
int main(){
   int arr[2][2]; 
   CK& rf0 = arr;  // ok, qualification conversion 
   CK& rf = const_cast<CK&>(arr);  // ill-formed, the requirement is not satisfied
}

Change [expr.const.cast] p3 to

For any casting from an expression of type T1 to type T2 using a const_cast, considering the qualification-decompositions of both types, each P¹_i shall be the same as P² _i for all i. The result of a const_­cast refers to the original entity.

The rules defined in the subsequence paragraphs that use const_cast casting all should satisfy this precondition.

---

Another issue appears in [expr.const.cast] p7: U1 suddenly appears without any introduction. Maybe, change it to

A conversion from a type T1 to a type T2 casts away constness if T1 and T2 are different, there is a qualification-decomposition ([conv.qual]) of T1

cv¹₀ P¹₀ cv¹₁ P¹₁ ... cv¹_n-1 P¹_n-1 cv¹_n U₁

yielding n such that T2 has a qualification-decomposition of the form

cv²₀ P²₀ cv²₁ P²₁ ... cv²_n-1 P²_n-1 cv²_n U₂

and there is no qualification conversion that converts T1 to

cv²₀ P¹₀ cv²₁ P¹₁ ... cv²_n-1 P¹_n-1 cv²_n U₁

would be more clear.

[jensmaurer]

For the first concern, note that [expr.cast] tries a number of casts in turn. Hitting "shall" = ill-formed too soon terminates the if ladder too soon.

[xmh0511]

For the first concern, note that [expr.cast] tries a number of casts in turn. Hitting "shall" = ill-formed too soon terminates the if ladder too soon.

It seems that const_cast can only convert the types if their corresponding Pi are the same. There seems to have no exception here. The types specified in P4 still should satisfy those requirements. Such as this example:

typedef int CK[][2];
int arr[2][2]; 
const_cast<CK&>(arr);

which is the case specified by [expr.const.cast] p4.1, where T1 is int [2][2] and T2 is int [][2].

The qualification-decompositions of them are: pointer to array of 2 array of 2 int vs. pointer to array of unknown bound of array of 2 int.

where P¹₁ is not the same as P²₁.

[jensmaurer]

While that's true, it doesn't address the concern: We want "const_cast" simply to not be applicable and the ladder in [expr.cast] to go to the next step (e.g. static_cast). If we make the "const_cast" ill-formed before locking in to that choice, we'll never get to "static_cast" etc. in [expr.cast].

[xmh0511]

we'll never get to "static_cast" etc. in [expr.cast].

How would static_cast be used in a const_cast conversion? I cannot figure out that example. Would you specify that?

[jensmaurer]

Take this example:

int p;
(void *)&p;

[expr.cast] first attempts a const_cast from int* to void *. But that fails, so it attempts a static_cast next. That succeeds, and all is well.

If, however, we say the attempt to form the const_cast is ill-formed, we'll never reach the static_cast attempt.

[xmh0511]

Alright. I forgot the existence of [expr.cast] p4. Since we mentioned [expr.cast] p4, I think out an example that is not well specified by [expr.cast] p4 but it may be another issue.

int const p = 0;
(void*)&p;

a static_­cast followed by a const_­cast may be a matched interpretation. However, we didn't specify the temporary middle type in the conversion sequence, in other words, whether the conversion be interpreted to:
const_cast<void*>(static_cast<void*>(&p)) or const_cast<void*>(static_cast<void const*>(&p)), the former is ill-formed since static_cast casts away constness. I remember I saw this issue somewhere, I will cite the question here if I find it.

[jensmaurer]

Yes, the implementation needs to pick a suitable middle type. "shall not cast away constness" is probably the wrong phrasing, then. It should be "cannot cast away constness", it seems.

[xmh0511]

@jensmaurer we may specify the middle type by replacing the U in the qualification-decomposition of the source type. This issue sources from https://stackoverflow.com/questions/39216316/does-the-c-specification-say-how-types-are-chosen-in-the-static-cast-const-cas

[jensmaurer]

We don't need to specify the middle type; if there is any, the cast works. The implementation can figure that out.

[xmh0511]

We don't need to specify the middle type; if there is any, the cast works. The implementation can figure that out.

Does it mean the result is implementation-defined? Since only implementation clearly knows how the conversion chain works.

[jensmaurer]

Does it mean the result is implementation-defined?

No. The underlying assumption is that the end result is the same, regardless of which middle type was chosen. Do you have a counterexample?

[xmh0511]

Do you have a counterexample?

Consider this example:

struct B0{
	int b0;
};
struct B1{
	int b1;
};

struct D:B0,B1{
};

struct Trick{
	Trick() = default;
	Trick(std::any){

	}
	template<class T>
	operator T(){
		return T{0};
	}
};
int main(){
   D const* Dptr = new D;
   B1* ptr = (B1*)Dptr; // #1
}

For the cast notation conversion that occurs at #1, the options can be these

Sane options

const_cast<D*>(Dptr);  // a expected result

const_cast<B1*>(static_cast<B1 const*>(Dptr)); // a expected result

const_cast<D*>(static_cast<D const*>(Dptr));  // a possible option, the standard conversion can apply to the result

const_cast<B1*>(reinterpret_cast<B1 const*>(Dptr));  // the result is the same as the value of Dptr

Insane options

static_cast<Trick>(Dptr); // insane but it is true since we didn't specify the middle type

Maybe, there are some other weird options. And in the sane options group, there are two static_­cast followed by a const_­cast, the program can be ill-formed as long as the implementation prefers. Furthermore, how to interpret the conversion relies on what the middle type the implementations would like. what about an insane implementation that selects the Trick as a middle type? That means, static_cast<Trick>(Dptr); is the first option in the list.

---

Incidentally

If a conversion can be interpreted in more than one way as a static_­cast followed by a const_­cast

This is unclear how more than one interpretation intends? Does it mean there is more than one interpretation in the situation where the middle type should be the same or arbitrary middle types?

[jensmaurer]

If a conversion can be interpreted in more than one of the ways listed above, the interpretation that appears first in the list is used, even if a cast resulting from that interpretation is ill-formed.

Thus, the list is an ordered list: if a single const_cast suffices, we'll take that. So, we pick the const_cast<D*>(Dptr) interpretation.

The sentence doesn't talk about middle types, so it's for any middle type.

[xmh0511]

The sentence doesn't talk about middle types, so it's for any middle type.

Only when the middle type is D* will const_cast<D*>(Dptr) be firstly picked. Why wouldn't the implementation picks Trick as the middle type and thus static_cast<Trick>(Dptr); is the first picked one?

Or, do you mean for a given set S of possible middle types, which may be { Trick, D*, ...}, const_cast<D*>(Dptr) first appears in the list, so it is picked by implementation?

However, it still cannot interpret the program will be ill-formed since there is more than one way as a static_­cast followed by a const_­cast for that given set S.
const_cast<B1*>(static_cast<B1 const*>(Dptr)); and const_cast<D*>(static_cast<D const*>(Dptr)); Should we change that to

If a conversion can be interpreted in more than one way as a static_­cast followed by a const_­cast that is used, the conversion is ill-formed.

which implies that a static_­cast followed by a const_­cast first appears in the list for the given set S.

[jensmaurer]

For the first (const_cast) option, there is no middle type. Anyway, my interpretation is that you try the first option, iterating through all possibilities if necessary. If you can form a conversion ("can be converted"), you pick that conversion (which might end up being ill-formed nonetheless). For your example, we never look at the second and further options.