Насколько я понимаю, все компиляторы неправильные, и программа должна быть некорректной.

Связанных с работой

Существует отправленный, но еще не пронумерованный выпуск CWG , где @BrianBi объясняет этот сценарий, а также приходит к выводу, что формулировка подразумевает неправильную формулировку.

С другой стороны, @Barry скомпилировал эти комбинации типов в условном операторе в P3177R0 и утверждает, что const S будет создано. Однако эти данные нельзя использовать для каких-либо выводов, поскольку они были собраны путем простого анализа результатов GCC, а не путем анализа стандартных формулировок.

Языковое адвокатство

Чтобы в итоге определить правильный тип, рассмотрим правила определения типа условного оператора в [expr.cond]. Помимо прочего, в ... ? f() : g() компилятор пытается преобразовать f() в g() и g() в f(), как описано в [expr.cond] p4.

Шаг 1. Определение типов целей

Для вышеупомянутых преобразований компилятор определяет целевые типы для обеих последовательностей неявного преобразования.

Обратите внимание, что:

• f() имеет тип const S&&, который перед любым анализом превратится в значение x типа const S ([expr.type] p1), и
• g() — это значение типа S.

Преобразование из f() в тип, связанный с S

Это преобразование происходит в соответствии с [expr.cond] p4.3:

Если E2 является значением prvalue или если ни одна из приведенных выше последовательностей преобразования не может быть сформирована и хотя бы один из операндов имеет тип класса (возможно, с указанием cv): [...]

g() — это ценное значение, так что это соответствующий случай.

Поскольку const S и S являются одним и тем же типом класса (игнорируя cv-квалификацию), но S менее подходит для cv, [expr.cond] p4.3.1 не применяется, а применяется преобразование lvalue в rvalue до E2, то есть g() ( [expr.cond] p4.3.3):

в противном случае целевой тип — это тип, который будет иметь E2 после применения стандартных преобразований lvalue-to-rvalue, массива-указателя и функции-указателя.

Результат: тип цели: S.

Примечание. E2 — это g(), и ни одно из перечисленных преобразований не применимо, однако это нормально. Поскольку вы, очевидно, не можете применить все три перечисленных преобразования, цель формулировки состоит в том, чтобы применить любое из этих преобразований, если это возможно. Другими словами, тип цели — это просто E2, к которому ничего не применяется.

Преобразование из g() в тип, связанный с const S

Если E2 является значением x, целевым типом является «ссылка rvalue на T2», но последовательность неявного преобразования может быть сформирована только в том случае, если ссылка будет привязана напрямую.

- [expr.cond] п4.2

Все условия здесь удовлетворены, учитывая, что f() является значением x, а ссылка const S&& может напрямую связываться со значением prvalue типа S ( [dcl.init.ref] p5.3.1).

Результат: тип цели — «ссылка на rvalue на const S».

Шаг 2. Неявные преобразования

Теперь компилятор проверяет, можно ли выполнить неявные преобразования с заданными целевыми типами.

• f() можно преобразовать в S с помощью неявно определенного (тривиального) конструктора копирования, который будет вызываться как часть определяемой пользователем последовательности преобразования , и
• g() можно преобразовать в const S&&, просто привязав ссылку.

Теперь мы должны столкнуться с [expr.cond] p4, предложение 5:

Если обе последовательности могут быть сформированы или одна может быть сформирована, но это неоднозначная последовательность преобразования, программа является неправильной.

На этом этапе компилятор должен отклонить код, однако никто этого не делает.

Перспектива GCC/clang

Если бы мы продолжали работать так, как будто программа не была правильно сформирована, мы бы столкнулись с [expr.cond] p6:

В противном случае результатом будет prvalue. [...] В противном случае применяются определенные таким образом преобразования, и преобразованные операнды используются вместо исходных операндов в оставшейся части этого подраздела.

Результатом является prvalue, и мы применяем последний этап преобразования lvalue в rvalue, чтобы получить g() (поскольку оно было преобразовано в ссылку rvalue). Судя по всему, GCC считает, что это значение prvalue должно быть типа const S, но нам не следовало доходить до этого момента.

Поскольку результатом является prvalue и decltype не применяется к непарному выражению идентификатора, decltype должно выдавать S или const S ([dcl.type.decltype] p1.6).

Перспектива MSVC

MSVC, вероятно, думает, что одно из двух преобразований не удалось, и в этом случае результат может быть const S&&:

Если второй и третий операнды являются glvalues ​​одной и той же категории значений и имеют один и тот же тип, результат имеет этот тип и категорию значения и является битовым полем, если второй или третий операнд является битовым полем или если оба являются битовыми полями.

- [expr.cond] p5

Однако неясно, почему MSVC считает, что f() нельзя преобразовать в S, что привело бы к сценарию, в котором оба операнда теперь являются значениями x типа const S&&.