On Thu, 16 May 2024 at 23:10, Frederick Virchanza Gotham via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Thu, May 16, 2024 at 3:24 PM Jason McKesson wrote:
> >
> > So you want the language to change in a way that can only be useful
> > for compiler-specific code, in order to do something you *can already
> > do* with the current language in a way that works on all compilers.
> >
> > This is not what "motivation" looks like.
>
>
> Actually, rather than try to make a new 'bit_cast', the real remedy
> here is for the Standard to mandate that an std::tuple shall be
> trivially copyable if all of its elements are trivially copyable, and
> so then we'll be able to use std::bit_cast on a std::tuple to pass it
> into a consteval hash function.
>
> I've done some web searching to try ascertain why std::tuple isn't
> guaranteed by the Standard to be trivially copyable if all of its
> elements are trivially copyable, and I've seen explanations along the
> lines of "It's just too complicated to implement on top of the
> existing implementations and it gets a bit hairy". Well I think I have
> it working for libstdc++ by changing 21 lines in the <tuple> header
> file, you can see my changes here:
>
>
> https://github.com/healytpk/tuple_trivially_copyable/commit/b274f779075d2c53664da0a159dbafa10d668f10
>
> Tomorrow I'll try make a similar patch for the Microsoft
> implementation of std::tuple. Then if I have a viable patch file for
> both compilers, I think it would make sense to write a paper to
> propose that std::tuple shall be trivially copyable whenever all of
> its elements are trivially copyable. Same goes for std::pair.
>

That patch will not be accepted to libstdc++.

It makes the ABI differ between C++20 and older standards without concepts,
so is a hard no.

If you want to amuse yourself with these kind of experiments that's fine,
but it's waste of time on this mailing list. This isn't the place for idle
games and experiments for your own amusement.