P3921R0 issue 1670

[eisenwave]

Fixes #8456.
Fixes FI-4 (C++14 CD).

Note that this PR also fixes an example in [class.conv.fct] that becomes clearly incorrect after CWG1670 is applied.

[frederick-vs-ja]

Currently, there's one such use made invalid by CWG1670 in the library specification.

draft/source/meta.tex

Line 850 in 605dcaa

constexpr operator decltype(auto)() const noexcept { return value; }

It seems OK to replace operator decltype(auto) with operator decltype(value) without diverging from the intent. Do we want to fix the library wording in this PR, another PR, or a follow-up LWG issue?

[eisenwave]

That's technically a normative change, and I would prefer to keep this PR minimal so we don't run into anything that prevents us from merging motions.

The fix of [class.conv.fct] was clearly just a minor editorial adjustment, but the operator decltype(auto) thing should be fixed elsewhere. Maybe that will even turn into an LWG issue; I hope not.

[eisenwave]

You know what, I'm just going to submit an LWG issue for this.

[Dani-Hub]

We have now LWG 4468 for this.

[tkoeppe]

Thanks, @Dani-Hub!

[t3nsor]

It seems to me that the entire paragraph "A conversion function template shall not have a deduced return type" should go away.

Technically, that might (?) actually be a normative change in that the current rule makes the template operator auto clearly ill-formed whereas if that rule is struck then it might be IFNDR under [temp.res.general], but there seems to be little value in having this special case.

[eisenwave]

It seems to me that the entire paragraph "A conversion function template shall not have a deduced return type" should go away.

I wouldn't be opposed, but that seems more like CWG issue material than a drive-by fix in this PR which applies the motions.