It would seem that MSVC and ICC also give `const S`.

https://www.godbolt.org/z/ejen4_

On Tue, Sep 24, 2019 at 12:09 PM Tom Honermann <tom@honermann.net> wrote:
On 9/24/19 12:14 PM, Brian Bi via Std-Discussion wrote:
Thanks for the responses, everyone.

Can someone remind me which the "big 4" compilers are? Did they all consider the result type to be `const S`?

Such references generally refer to gcc, Clang, MSVC, and EDG derived compilers such as Intel's ICC

You can test all of them (as well as some others) at https://www.godbolt.org.

Tom.


(It seems that it is time to open a core issue and I would like to mention this as part of the report.)

On Tue, Sep 24, 2019 at 4:42 AM Krystian Stasiowski via Std-Discussion <std-discussion@lists.isocpp.org> wrote:
Oops. Here it is again:

I'm going to break it down, word by word, lets see how this goes. Please, fact check this!

#include <type_traits>
struct S {};
bool b;
int main()
{
    const S s{};
    static_assert(std::is_same<decltype(b ? S{} : s), const S>::value);
} 
 
Here, http://eel.is/c++draft/expr.cond#4 applies because S{} and s have differing types (S and const S). Therefore, we must form a implicit conversion sequence between the two:

Given E1 is S{}, E2 is s, T1 is S and T2 is const S:
- E2 is an lvalue, therefore the target type is const S& http://eel.is/c++draft/expr.cond#4.1. The target is a reference type, so we follow the rules of  http://eel.is/c++draft/over.ics.ref  
  - S{} binds directly to the reference. The conversion is an identity conversion. http://eel.is/c++draft/over.ics.ref#1
  - http://eel.is/c++draft/expr.cond#4.1 mandates that the reference must bind directly to the glvalue. This is the first point of divergence: If this is indeed referring to the operand itself, in this case S{}, without the temporary materialization conversion applied, then this sub clause does not apply, and instead the rules of http://eel.is/c++draft/expr.cond#4.3 apply, which state that in this case, since T2 is al least as cv-qualified as T1, the target type is T2, and a conversion sequence is formed; the result is the same for both. However, this would stop us dead in our tracks, and make the program ill-formed. I don't believe this is intended. We will assume this is unintentional, and throw in the possibility that the conversion sequence cannot be formed, assuming that http://eel.is/c++draft/expr.cond#4.1 really does require E1 to be a glvalue without the temporary materialization conversion applied. 

Now, the calculation is complete. The conversion sequence for S{} to s is either not able to be formed, or is an identity conversion.

Now, for the second sequence:
Given E1 is s, E2 is S{}, T1 is const S and T2 is S:
- E2 is a prvalue so http://eel.is/c++draft/expr.cond#4.3 applies. T2 is less cv-qualified than T1, so 4.3.1 does not apply. T2 is not a base class, so 4.3.2 does not apply. Therefore, the target type is the type of E2 after the lvalue-to-rvalue, function-to-pointer, and array to pointer conversions are applied - these have no effect. The target type is S.
- The target type is not a reference, so http://eel.is/c++draft/over.best.ics#6 applies. The conversion sequence is the one that converts E2 to a prvalue of of target type, S http://eel.is/c++draft/over.best.ics#6.sentence-2. Top level cv-qualifiers are ignored http://eel.is/c++draft/over.best.ics#6.sentence-4. As they are ignored, and they both have the same class type, the conversion is an identity conversion http://eel.is/c++draft/over.best.ics#6.sentence-7

Side note: The standard kinda disagrees with itself here, it first states "The implicit conversion sequence is the one required to convert the argument expression to a prvalue of the type of the parameter." (http://eel.is/c++draft/over.best.ics#6.sentence-2) and also says "When the parameter has a class type and the argument expression has the same type, the implicit conversion sequence is an identity conversion.". We will assume that it means the later since it is more constrained, and therefore does not include the lvalue-to-rvalue conversion. This does not change the later result, as a lvalue-to-rvalue conversion would not discard the cv-qualifiers https://eel.is/c++draft/conv.lval#1

This calculation is complete. The conversion sequence for s to S{} is an identity conversion. 

Here are our two options now:
1. The conversion sequence for S{} to s cannot be formed, so the conversion sequence for s to S{} is applied to s http://eel.is/c++draft/expr.cond#4.sentence-7. It has no effect on value category or type, as no conversion is performed.
2. Both conversion sequences are formed, making the program ill-formed. http://eel.is/c++draft/expr.cond#4.sentence-5

Since option 2 makes the program ill-formed, and the big 4 all agree that this is a well-formed construct, we can assume that it does mean that in the case of  https://eel.is/c++draft/expr.cond#4.1  E1 must be a glvalue, the reference must bind directly to it, and http://eel.is/c++draft/expr.cond#4.3 will not kick in to form that implicit conversion sequence.

From this point on, we will refer to the converted operands as CE1, and CE2 (even though only an identity conversion was done)

Now for option 1:
- EC1 and EC2 do not have the same value category, nor the same type, so  http://eel.is/c++draft/expr.cond#5  does not apply. This means the result is a prvalue. http://eel.is/c++draft/expr.cond#6
- Since the types of EC1 and EC2 differ, and both are class types, http://eel.is/c++draft/expr.cond#6 say "overload resolution is used to determine the conversions (if any) to be applied to the operands" and cross-references http://eel.is/c++draft/over.match.oper#3.3  and  http://eel.is/c++draft/over.match.oper.

This is the second point of divergence, built in candidates are defined for the conditional operator, but since it is not a binary operator nor a unary operator, the entirety of  http://eel.is/c++draft/over.match.oper#3 does not apply. The note http://eel.is/c++draft/over.match.oper#1.sentence-3 does state that the rules in the sub-clause are used to determine the conversions applied to the operands, but there is no such clause in http://eel.is/c++draft/over.match.oper that describes this behavior in our case (nor even a semblance of one). http://eel.is/c++draft/over.match.oper#2 says that overload resolution is performed to determine which built-in operator will be used. However, the only candidates defined (http://eel.is/c++draft/over.built#27 and http://eel.is/c++draft/over.built#28) do not include class types, and since S cannot be converted to an arithmetic type, pointer type, pointer to member type or scoped enumeration type, none of these will be selected. This is definitely not intended, since it would only work for class types convertible to arithmetic, pointer, pointer to member and scoped enumeration types.

WARNING: HERE BE SPECULATION LAND

This leaves us with two options, the construct is ill-formed, or we can assume make an educated guess based on the text. Since all compilers tested accept this, we can assume that there is some invented built in candidate T operator?:(bool, T, T); Where T is determined as follows.
- If both operands are of the same class type (ignoring cv-qualification), the T is the cv-combined type of the types of both operands
- Otherwise, if only one operand is of (possibly cv-qualified) class type U, T is U
- Otherwise, if both are class types, an attempt is made to form conversion sequences between the two. If both are formed, or none are, the program is ill-formed. Otherwise, T is the target type of the conversion sequence that was formed.

(This is by no means correct, just a rough outline based on my observations of the behavior of clang and gcc. This should replicated the behavior, but I have not tested all possible cases)

This would result in overload resolution selecting this invented operator function, and the operands would be converted to the types of the parameters http://eel.is/c++draft/over.match.oper#10. When applied to our case, the converted operands are of type S and const S; the cv-combined type of these is const S, leading both operands being converted to const S. Now that the types match exactly, http://eel.is/c++draft/expr.cond#7 applies, and the lvalue-to-rvalue, array-to-pointer, and function-to-pointer standard conversions are performed on the second and third operands, and the result is of type const S, which is what clang and gcc report.

Here is the final tally of possible behaviors:
1. Both conversion sequences are formed, making the program ill-formed (I don't consider this an option, I just included it here for the sake of being complete)
2. Only the s to S{} sequence is formed, but no built in candidate exists for T operator?:(T, T) where T is a class type. Overload resolution fails, and the program is ill formed.
3. Only the s to S{} sequence is formed, and there exists a candidate function T operator?:(T, T) where T is const S. Overload resolution is successful, and both operands are converted to const S. The expression is a prvalue of type const S.

Option 3 is the one that best illustrates the behavior of the major compilers, so even though it uses some extrapolated wording, I believe this is what is actually happening. After spending 2.5 hours researching this and tracing it though the standard, I think its safe to say that this wording is defective. I think that the fact that top level cv-qualifiers are ignored when forming a implicit conversion sequence was overlooked when this was written, or perhaps the wording was changed, and this was just never updated.

-------- Original message --------
From: Andrew Schepler via Std-Discussion <std-discussion@lists.isocpp.org>
Date: 9/24/19 05:21 (GMT-05:00)
Cc: Andrew Schepler <aschepler@gmail.com>
Subject: Re: [std-discussion] Conditional operator with const lvalue and non-const prvalue

It looks like you accidentally sent that last message to just me, and not the mailing list:

On Tue, Sep 24, 2019 at 12:29 AM Krystian Stasiowski <sdkrystian@gmail.com> wrote:
I'm going to break it down, word by word, lets see how this goes. Please, fact check this!

#include <type_traits>
struct S {};
bool b;
int main()
{
    const S s{};
    static_assert(std::is_same<decltype(b ? S{} : s), const S>::value);
} 
 
Here, http://eel.is/c++draft/expr.cond#4 applies because S{} and s have differing types (S and const S). Therefore, we must form a implicit conversion sequence between the two:

Given E1 is S{}, E2 is s, T1 is S and T2 is const S:
- E2 is an lvalue, therefore the target type is const S& http://eel.is/c++draft/expr.cond#4.1. The target is a reference type, so we follow the rules of  http://eel.is/c++draft/over.ics.ref  
  - S{} binds directly to the reference. The conversion is an identity conversion. http://eel.is/c++draft/over.ics.ref#1
  - http://eel.is/c++draft/expr.cond#4.1 mandates that the reference must bind directly to the glvalue. This is the first point of divergence: If this is indeed referring to the operand itself, in this case S{}, without the temporary materialization conversion applied, then this sub clause does not apply, and instead the rules of http://eel.is/c++draft/expr.cond#4.3 apply, which state that in this case, since T2 is al least as cv-qualified as T1, the target type is T2, and a conversion sequence is formed; the result is the same for both. However, this would stop us dead in our tracks, and make the program ill-formed. I don't believe this is intended. We will assume this is unintentional, and throw in the possibility that the conversion sequence cannot be formed, assuming that http://eel.is/c++draft/expr.cond#4.1 really does require E1 to be a glvalue without the temporary materialization conversion applied. 

Now, the calculation is complete. The conversion sequence for S{} to s is either not able to be formed, or is an identity conversion.

Now, for the second sequence:
Given E1 is s, E2 is S{}, T1 is const S and T2 is S:
- E2 is a prvalue so http://eel.is/c++draft/expr.cond#4.3 applies. T2 is less cv-qualified than T1, so 4.3.1 does not apply. T2 is not a base class, so 4.3.2 does not apply. Therefore, the target type is the type of E2 after the lvalue-to-rvalue, function-to-pointer, and array to pointer conversions are applied - these have no effect. The target type is S.
- The target type is not a reference, so http://eel.is/c++draft/over.best.ics#6 applies. The conversion sequence is the one that converts E2 to a prvalue of of target type, S http://eel.is/c++draft/over.best.ics#6.sentence-2. Top level cv-qualifiers are ignored http://eel.is/c++draft/over.best.ics#6.sentence-4. As they are ignored, and they both have the same class type, the conversion is an identity conversion http://eel.is/c++draft/over.best.ics#6.sentence-7

Side note: The standard kinda disagrees with itself here, it first states "The implicit conversion sequence is the one required to convert the argument expression to a prvalue of the type of the parameter." (http://eel.is/c++draft/over.best.ics#6.sentence-2) and also says "When the parameter has a class type and the argument expression has the same type, the implicit conversion sequence is an identity conversion.". We will assume that it means the later since it is more constrained, and therefore does not include the lvalue-to-rvalue conversion. This does not change the later result, as a lvalue-to-rvalue conversion would not discard the cv-qualifiers https://eel.is/c++draft/conv.lval#1

This calculation is complete. The conversion sequence for s to S{} is an identity conversion. 

Here are our two options now:
1. The conversion sequence for S{} to s cannot be formed, so the conversion sequence for s to S{} is applied to s http://eel.is/c++draft/expr.cond#4.sentence-7. It has no effect on value category or type, as no conversion is performed.
2. Both conversion sequences are formed, making the program ill-formed. http://eel.is/c++draft/expr.cond#4.sentence-5

Since option 2 makes the program ill-formed, and the big 4 all agree that this is a well-formed construct, we can assume that it does mean that in the case of  https://eel.is/c++draft/expr.cond#4.1  E1 must be a glvalue, the reference must bind directly to it, and http://eel.is/c++draft/expr.cond#4.3 will not kick in to form that implicit conversion sequence.

From this point on, we will refer to the converted operands as CE1, and CE2 (even though only an identity conversion was done)

Now for option 1:
- EC1 and EC2 do not have the same value category, nor the same type, so  http://eel.is/c++draft/expr.cond#5  does not apply. This means the result is a prvalue. http://eel.is/c++draft/expr.cond#6
- Since the types of EC1 and EC2 differ, and both are class types, http://eel.is/c++draft/expr.cond#6 say "overload resolution is used to determine the conversions (if any) to be applied to the operands" and cross-references http://eel.is/c++draft/over.match.oper#3.3  and  http://eel.is/c++draft/over.match.oper.

This is the second point of divergence, built in candidates are defined for the conditional operator, but since it is not a binary operator nor a unary operator, the entirety of  http://eel.is/c++draft/over.match.oper#3 does not apply. The note http://eel.is/c++draft/over.match.oper#1.sentence-3 does state that the rules in the sub-clause are used to determine the conversions applied to the operands, but there is no such clause in http://eel.is/c++draft/over.match.oper that describes this behavior in our case (nor even a semblance of one). http://eel.is/c++draft/over.match.oper#2 says that overload resolution is performed to determine which built-in operator will be used. However, the only candidates defined (http://eel.is/c++draft/over.built#27 and http://eel.is/c++draft/over.built#28) do not include class types, and since S cannot be converted to an arithmetic type, pointer type, pointer to member type or scoped enumeration type, none of these will be selected. This is definitely not intended, since it would only work for class types convertible to arithmetic, pointer, pointer to member and scoped enumeration types.

WARNING: HERE BE SPECULATION LAND

This leaves us with two options, the construct is ill-formed, or we can assume make an educated guess based on the text. Since all compilers tested accept this, we can assume that there is some invented built in candidate T operator?:(bool, T, T); Where T is determined as follows.
- If both operands are of the same class type (ignoring cv-qualification), the T is the cv-combined type of the types of both operands
- Otherwise, if only one operand is of (possibly cv-qualified) class type U, T is U
- Otherwise, if both are class types, an attempt is made to form conversion sequences between the two. If both are formed, or none are, the program is ill-formed. Otherwise, T is the target type of the conversion sequence that was formed.

(This is by no means correct, just a rough outline based on my observations of the behavior of clang and gcc. This should replicated the behavior, but I have not tested all possible cases)

This would result in overload resolution selecting this invented operator function, and the operands would be converted to the types of the parameters http://eel.is/c++draft/over.match.oper#10. When applied to our case, the converted operands are of type S and const S; the cv-combined type of these is const S, leading both operands being converted to const S. Now that the types match exactly, http://eel.is/c++draft/expr.cond#7 applies, and the lvalue-to-rvalue, array-to-pointer, and function-to-pointer standard conversions are performed on the second and third operands, and the result is of type const S, which is what clang and gcc report.

Here is the final tally of possible behaviors:
1. Both conversion sequences are formed, making the program ill-formed (I don't consider this an option, I just included it here for the sake of being complete)
2. Only the s to S{} sequence is formed, but no built in candidate exists for T operator?:(T, T) where T is a class type. Overload resolution fails, and the program is ill formed.
3. Only the s to S{} sequence is formed, and there exists a candidate function T operator?:(T, T) where T is const S. Overload resolution is successful, and both operands are converted to const S. The expression is a prvalue of type const S.

Option 3 is the one that best illustrates the behavior of the major compilers, so even though it uses some extrapolated wording, I believe this is what is actually happening. After spending 2.5 hours researching this and tracing it though the standard, I think its safe to say that this wording is defective. I think that the fact that top level cv-qualifiers are ignored when forming a implicit conversion sequence was overlooked when this was written, or perhaps the wording was changed, and this was just never updated.

On Mon, Sep 23, 2019 at 7:42 PM Andrew Schepler <aschepler@gmail.com> wrote:
Yes, the conversion from prvalue S{} to type const S& would bind directly, but it "is said to bind directly to the initializer expression", and the initializer expression "S{}" is not a glvalue. A bit confusing, since the reference "binds to" the lvalue resulting from the temporary materialization conversion. But I think this is intended, because I think the point is that a temporary materialization conversion is never applied to just one of the second or third operands of the conditional. If it did, automatically destroying the temporary at the end of its lifetime would depend on more than just the program counter register, causing brand new complications for compilers, particularly for stack unwinding on exception propagation.

There certainly is an implicit conversion sequence from an lvalue of type const S to type S, via the copy constructor. Otherwise we couldn't do:

struct S {};
void f(S) {}
int main() {
    const S s;
    f(s);
}

But in converting "S{}" to a type related to "s", wouldn't [expr.cond]/(4.3) apply, if the conversion in [expr.cond]/(4.1) is not possible? Note there have been changes to (4.3) since C++17:

C++17 N4659:
(4.3.1) if T1 and T2 are the same class type (ignoring cv-qualification), or one is a base class of the other, and T2 is at least as cv-qualified as T1, the target type is T2,
(4.3.2) otherwise, ...

(4.3.1) if T1 and T2 are the same class type (ignoring cv-qualification) and T2 is at least as cv-qualified as T1, the target type is T2,
(4.3.2) otherwise, if T2 is a base class of T1, the target type is cv1 T2, where cv1 denotes the cv-qualifiers of T1,
(4.3.3) otherwise, ...

But I don't see how that change would make any implicit conversion sequence unavailable. Which would mean both are possible and "b ? S{} : s" is ill-formed - not desirable. (It might make sense to say if both are possible and the target types are the same, the expression is a prvalue with that type; but it doesn't say that.)




On Mon, Sep 23, 2019 at 6:51 PM Krystian Stasiowski via Std-Discussion <std-discussion@lists.isocpp.org> wrote:
Only the last case where the initializer expression is converted does it not bind directly  http://eel.is/c++draft/dcl.init.ref#5.4

The implicit conversion sequence can be formed from the prvalue to the lvalue. Since constness matters for prvalues of class type and is not ignored, an implicit conversion sequence cannot be formed from const S to S. 

I think.

On Mon, Sep 23, 2019 at 11:02 AM Brian Bi via Std-Discussion <std-discussion@lists.isocpp.org> wrote:
Consider the following:

#include <type_traits>
struct S {};
bool b;
int main() {
    const S s {};
    static_assert(std::is_same<decltype(b ? S{} : s), const S>::value);
}

Here GCC and Clang confirm that the type is correct. But I can't figure out why. My reading of the standard is that the result should be a prvalue of type S, not const S.

[expr.cond]/4 applies because the two operand types are not the same (one is S, the other is const S) but at least one is a class type. We must therefore try to form an implicit conversion sequence in each direction. An implicit conversion sequence cannot be formed from the prvalue operand to const S& because (4.1) contains a restriction that the reference must bind directly to a glvalue. In the other direction, we have the identity conversion sequence from the const lvalue operand to S. Thus, /4 seems to tell us that the const lvalue operand must be converted to S, and the result should have type S.

Yet I would not expect both GCC and Clang to be wrong here, so I think that I have misunderstood the standard in this case. Surely there must be a reason why the result has type const S, but I can't figure it out.

(Even if we assume that the compiler is obligated to perform an lvalue-to-rvalue conversion on the const lvalue operand, resulting in a const prvalue, that still doesn't seem to explain the result. If this were the case, /4 would end with a const prvalue and a non-const prvalue, /5 would not apply, and we would get to /6 and the types would still not be the same. The "overload resolution" procedure prescribed there would fail since S can't be converted to any scalar types, making the program ill-formed. This interpretation thus cannot be correct either.)

--
Brian Bi
--
Std-Discussion mailing list
Std-Discussion@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
--
Std-Discussion mailing list
Std-Discussion@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion

"Identity conversion" does not mean there is no change in type or value category. It only means that the conversion sequence is associated with category "Identity conversion" for purposes of comparing which implicit conversion sequence is better during overload resolution. In [over.best.ics]/6, "Any difference in top-level cv-qualification is subsumed by the initialization itself and does not constitute a conversion." doesn't mean that the cv-qualifiers of the target type must match the expression type; it means that if the only difference in qualifiers is at the top level, the implicit conversion sequence used in comparisons doesn't include a qualification conversion. In the same paragraph, "When the parameter has a class type and the argument expression has the same type, the implicit conversion sequence is an identity conversion." also doesn't change the target type; it means that even if the actual initialization requires a move/copy constructor, the ICS category is Identity and the rank is Exact Match.

So the conversion of "s" to a type related to "S{}" can be from "const S" to "S". If we suppose that the conversion from "S{}" to a type related to "s" cannot be formed, I agree the final type should be "S" and not "const S". Though I still don't see why (4.3) wouldn't apply to the conversion of "S{}" if (4.1) doesn't. Possibly the Standard wording there could be fixed or clarified.

I also agree there seems to be some wording missing about exactly when and how overload resolution is involved in semantic analysis of the conditional expression. Something should say that it goes through the same process as unary and binary expressions in [over.match.oper] using the phony name "operator?:", but the only candidate functions are the built-in candidate set. But I think it's intentional that [over.built] does not include any signatures involving class types, because getting past [expr.cond]/5 to the "Otherwise" [expr.cond]/6 where overload resolution gets involved is meant to be just for cases where the types aren't similar enough to use "Exact Match" or "Derived To Base" conversion sequences, and we can't convert either expression to the other's type, so the final option is to use one or two conversion functions to convert each class type operand to a non-class type.

Though this is backwards from the normal pattern: for most compound expressions, we can start with [over.match.oper]. At the very start, it says overloading does not apply if no operand has class or enum type, so only [expr] applies. Otherwise, overload resolution determines whether the compound expression is a function call or has the "built-in" meaning in [expr], and if it has the built-in meaning, the selected built-in candidate function determines any conversions to be applied before the semantics of [expr]. For a ternary conditional expression, it only makes sense to start analysis at [expr.cond]. If we pass the "Otherwise" at the start of [expr.cond], then [over.match.oper] applies, forcing the result type to be a non-class type. If that's really how it should be read, I think it would be good to have something mention that exception.

(Some of your phrasing seems to imply "since compilers do this, the Standard must be interpreted in a way consistent with that result", and I'd be careful about that reversal. Compiler teams are capable of error, and there might be some common reason multiple implementations use logic that matches the Standard most of the time but happens to give a consistent different result in one corner case not specifically intended. There's also the possibility the Standard has a defect or insufficiently clear wording. And of course common sense can enter into it: if selecting one of two expressions with a type differing only by "const" can ever make the code ill-formed, something is wrong.)

--
Std-Discussion mailing list
Std-Discussion@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion


--
Brian Bi




--
Brian Bi