Wrong examples in [over.match.class.deduct]-p6

[mrussoLuxoft]

The two examples (with a7 and a8) from [over.match.class.deduct]-p6 (draft of Nov 2024):

template <class T> struct A {
  explicit A(const T&, ...) noexcept;               // #1
  A(T&&, ...);                                      // #2
};

...

template <class T> A(const T&, const T&) -> A<T&>;  // #3
template <class T> explicit A(T&&, T&&) -> A<T>;    // #4

...

A a7 = {0, i};      // error: #3 deduces to A<int&>, #1 and #2 declare same constructor
A a8{0,i};          // error: #3 deduces to A<int&>, #1 and #2 declare same constructor

are wrong, as preliminary discussed on:
https://lists.isocpp.org/std-discussion/2024/11/2715.php (and 2718.php)
https://lists.isocpp.org/std-discussion/2024/11/2736.php

Indeed, deduction fails because guides from #2 and #3 (see the full example in standard text or on godbolt link) are non matching better each other (see https://godbolt.org/z/oejf5P1Tc).
The aforementioned text reads, instead, that #3 wins (successful deduction) and then the error is because, consequently, constructors #1 and #2 ambiguate, which would be true in case the deduction had led to T = int&.

I would propose the following changes, one with the error about overload resolution between two deduction guides, and one where a deduction guide wins and two equivalent constructors are consequently generated, so that both topics of the original comments are shown. I guess it is not that important to select between copy-list-initialization (a7) or not (a8), as another example (see a5 in standard text) already shows that the explicit user-defined deduction guide is involved (as per the text of [over.match.list]).

A a7 = {0, i};      // error: #2 and #3 both match, overload resolution fails
A a8{i,i};          // error: #3 deduces to A<int&>, #1 and #2 declare same constructor

(see https://godbolt.org/z/9Ecf8943x)

Do you believe it is interesting to highlight that even #1 matches for a7 ? (but #3 wins compared to it).

See PR #7444

[t3nsor]

This needs to be a CWG issue

[mrussoLuxoft]

Sorry, first times for me.

Should I open this issue on another page ?
Or only waiting for someone else to review ?

[t3nsor]

https://github.com/cplusplus/CWG/issues

[mrussoLuxoft]

Done -> cplusplus/CWG#647
without PR there ?

So, I guess this current Issue will be closed, as well as PR #7444

Thank you.

[tkoeppe]

Hello @mrussoLuxoft -- thanks for getting in touch, but please slow down a bit. This is repository is only for editorial work, and not a general place to discuss or contribute to the Standard. Please don't send us a barrage of issues before getting acquainted with how the process works and where everything goes. E.g. we probably won't be able to look editorially at claims of language defects, which should be reported as technical issues.

E.g. see https://isocpp.org/std/submit-issue, https://github.com/cplusplus/draft/wiki/How-to-tell-if-an-issue-is-editorial.

[mrussoLuxoft]

Thank you @tkoeppe,
Sure, I see your point.

I am also trying first to filter any wrong thought by discussing on std-discussion, as well as going there only after being quite convinced or having discussed on other platforms while I was not.

Sorry for some wrong usage.

At the moment, I have cumulated some points around templates and I am trying to distribute over the time.