assigned to @ldionne

This happens because libc++ (as an extension) permits a std::tuple<int, int> to be constructed from a single int, with the second int being default-constructed. static_cast(d) in this case performs the same initialization as

Base b(d);

... which can choose either the tuple copy/move constructor, or the undersized tuple constructor from tuple elements. The former requires a derived-to-base conversion on d, but the latter has 'exact match' rank because the construct-from-elements constructor employs perfect forwarding (the user-defined conversion to int happens inside the constructor, not as part of the call).

So this is a libc++ bug: this is a case where its undersized tuple constructor is non-conforming.

I'm sick and tired of our tuple extensions :(

I wish we could just ship a strictly conforming std::tuple -- it's already hard enough.

Lets go ahead and remove them then.

I can write a paper later proposing them so we can provide them while being standards conforming.

Do you mean remove-remove, or remove but keep the ability to enable like it has been done for the implicit-constructor-with-reduced-arity extension?

I think remove remove, I don't know if anyone actually re-enables the extension.

Remove and see what breaks :-(

Fixed by

commit a3ab512
Author: Louis Dionne ldionne.2@gmail.com
Date: Wed Feb 10 16:19:50 2021 -0500

[libc++] Rewrite the tuple constructors to be strictly Standards conforming

This nasty patch rewrites the tuple constructors to match those defined
by the Standard. We were previously providing several extensions in those
constructors - those extensions are removed by this patch.

The issue with those extensions is that we've had numerous bugs filed
against us over the years for problems essentially caused by them. As a
result, people are unable to use tuple in ways that are blessed by the
Standard, all that for the perceived benefit of providing them extensions
that they never asked for.

Since this is an API break, I communicated it in the release notes.
I do not foresee major issues with this break because I don't think the
extensions are too widely relied upon, but we can ship it and see if we
get complaints before the next LLVM release - that will give us some
amount of information regarding how much use these extensions have.

Differential Revision: https://reviews.llvm.org/D96523