[dcl.init.ref]/5 Prevent prvalue type adjustment CWG2481 #2657
Conversation
|
The issue was spotted in https://stackoverflow.com/q/54381791/9585016 |
jensmaurer
added
the
decision-required
| the initializer expression is implicitly converted to a prvalue | ||
| of type ``\cvqual{cv1} \tcode{T1}''. | ||
| the initializer expression is implicitly converted to a prvalue of type \tcode{T1}, | ||
| then the type of the resulting prvalue is adjusted to ``\cvqual{cv1} \tcode{T1}''. |
There was a problem hiding this comment.
Seems clunky to convert to one type then adjust to another. There's also a risk that cv-qualifiers in the destination type of the implicit conversion could matter in some contexts. How about:
Otherwise, the initializer expression is implicitly converted to a prvalue of type ''cv1
T'' and the temporary materialization conversion is immediately applied; the reference is bound to the result of this conversion.
or similar?
There was a problem hiding this comment.
Do you think that it is clear that "immediately" means [expr.type]/2 does not apply?
jensmaurer
removed
the
decision-required
|
Editorial meeting: Use Richard's suggestion and add a note saying that the cv-removal for scalar prvalues is not done before the materialization. |
jensmaurer
added
the
changes requested
jensmaurer
changed the title
wg21bot
added
the
needs rebase
|
@languagelawyer: could you please rebase this and apply the above suggestion? |
|
This was fixed differently fc923d6 |
Fresh prvalues could fall prey to [expr.type]/2: "If a prvalue initially has the type “cv T”, where T is a cv-unqualified non-class, non-array type, the type of the expression is adjusted to T prior to any further analysis."
I've also rewritten the sentence in the semantic line breaks style.
However, this would be a wrong fix if it is decided to restore the "no cv-qualified non-class non-array prvalues" status quo (see #2655).
See CWG2481