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.

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²₁.

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].

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?

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.

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.

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.

@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

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

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.

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?

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?

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.

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.

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.

How about this suggestion?

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

Although the first const_cast option is picked since it first appears in the list, however, the example still can be interpreted in more than one way as a static_­cast followed by a const_­cast. const_cast<B1*>(static_cast<B1 const*>(Dptr)); and const_cast<D*>(static_cast<D const*>(Dptr));.

So, the net concern is that the relationship of the two sentences after the bullets in [expr.cast] p4 is unclear.

Yes. I think the change is reasonable. If there is more than one of the same kind of interpretations, the program is ill-formed because of the ambiguity(which one is selected). However, if there is an unambiguity option that first appears in the list and thus is used, it is regardless of whether the number of the interpretation that appears in the below is, it does not matter.

@jensmaurer I figure out a simple counterexample

struct Trick{
  Trick() = default;
  template<class T>
  Trick(T){}

  template<class T>
    operator T(){
    return T{0};
  }
};
int main(){
   int a = 0;
   char* ptr = (char*)&a
}

Anyway, const_cast is not a correct interpretation, static_cast<Trick>(&a) thus first appears in the list while the expected interpretation reinterpret_cast<char*>(&a) appears after the former.

I think we want all the involved casts to convert to a type similar to the type given as the type-id of the cast-expression. And we want the last conversion in each bullet to convert to the type-id.

I think we want all the involved casts to convert to a type similar to the type given as the type-id of the cast-expression. And we want the last conversion in each bullet to convert to the type-id.

Yes. That's the reason why I want to ask for some restrictions/requirements to the possible used types in the cast notation conversion. And it is exactly why I think the result may be implementation-defined If we do not specify some requirements

Instead of giving too much free room for implementation, It is better to minimum limit the types used in the conversion if possible.

we want all the involved casts to convert to a type similar to the type given as the type-id of the cast-expression

It seems that we just want any (middle) type used in static_cast or reinterpret_cast followed by a const_cast with the type as the following:

If The qualification-decomposition of the type T1 of the operand in the cast-expression is

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

yielding n (where n≥1 ) and the qualification-decomposition of the type T2 of the type-id in the cast-expression is

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

yielding m (where m≥1) such that a type T3 is

cv³₀ P²₀ cv³₁ P²₁ ... cv³_m-1 P²_m-1 cv³_m U₂

Conversion from T1 to T3 does not cast away constness

An implementation is permitted to chose a type T4 provide that a prvalue of T3 can be converted to T4 with a qualification conversion.

I'd really like to limit the cv and P ugly strings to a single subclause. Why is requiring "similar" not good enough?

Why is requiring "similar" not good enough?

Because, although the (middle) type is required to similar to type-id such that const_cast can be done, however, we have many cases that the type of the operand in a cast-expression is not similar to type-id. For example:

int const* const* ptr = 0;
(char* const* const*)ptr;

int const* const* is not similar to char* const* const* at all. Or, consider the inheritance case

struct B{};
struct D:B{};
D const d;
(B*) &d;

the type D const* is neither similar to B* nor B const*. I think [expr.const.cast] p7 has converted what we want here. In short, without cv and P ugly strings,

the (middle) type T3 should be similar to type-id and conversion from T1 to T3 does not cast away constness.

And we can give the creative space to implementations as long as they chose a type T4 such that T3 can be converted to T4 with a qualification conversion or T4 is just T3.

I was trying to suggest that any middle type employed in the sequence of casts be similar to type-id.
Yes, I understand that the type of the operand is likely not similar to anything.

I was trying to suggest that any middle type employed in the sequence of casts be similar to type-id.

Ah, I misunderstood what you said in the above comment. Yes, you're totally right, any (middle) type(s) used in the conversion should be similar to type-id(the destination type), and to not cast away constness have been required in each subclause except [expr.const.cast]. So, we only require that any middle type and type-id are similar is good enough.

For your example #5355 (comment) , I think there is a fundamental misunderstanding: We can't rely on any implicit conversions on the result of the static_cast or const_cast. And the operand of a const_cast must be a type similar to the target type of the const_cast.

I'm wondering if this issue can be resolved by simply saying that the last cast in each sequence in [expr.cast] p4 uses the type denoted by type-id as its target type.

Oh, and I would be interested in seeing an example for the "ambiguous static_cast / const_cast" case where an earlier case in the list is actually selected, with the understanding of the target type presented in the previous comment. If there is such a case, the linked pull request should be pursued.

I'm wondering if this issue can be resolved by simply saying that the last cast in each sequence in [expr.cast] p4 uses the type denoted by type-id as its target type.

Yes, I think this is necessary to add to the pull request to avoid a misunderstanding similar to #5355 (comment)

After the restriction to say the type of the last conversion should be the type-id, then for the concern mentioned in #5355 (comment), I'm wondering whether it is necessary to emphasize say the employed type of the first conversion in the conversion sequence formed by static_cast followed by const_cast or reinterpret_­cast followed by a const_­cast should be similar to type-id or not. the second conversion formed by const_cast can only process two similar types. If static_cast followed by const_cast or reinterpret_­cast followed by a const_­cast is used, this implies that the employed type in the middle conversion must be a similar type to type-id(the type that be restricted in the last conversion), otherwise, such a conversion cannot be formed.

Oh, and I would be interested in seeing an example for the "ambiguous static_cast / const_cast" case where an earlier case in the list is actually selected, with the understanding of the target type presented in the previous comment.

 int**** ptr = 0;
 auto t = (int const*const*const*const*)ptr;

this can be interpreted as

1. static_cast<int const * const * const * const * >(ptr);
2. const_cast<int const * const * const * const * >(static_cast<int * * * const * >(ptr));
3. const_cast<int const * const * const * const * >(static_cast<int * * const * const * >(ptr));
4. const_cast<int const * const * const * const * >(static_cast<int * const * const * const * >(ptr));
5. const_cast<int const * const * const * const *>(static_cast<int const * const * const * const *>(ptr));

From 2 to 5, they all be a static_­cast followed by a const_­cast, hence they are ambiguous, however, option 1 is an earlier case in the list, regardless of how many interpretations of a static_­cast followed by a const_­cast can have, it does not matter since the options that follow 1 are not used.

Thanks.

CWG2828

Should have been fixed by #6906 (0e026f5).