Date: Fri, 17 May 2024 08:40:15 +0100
On 16 May 2024 23:08:48 BST, 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.
Making these trivially copyable would be an ABI change, as they would get passed around in registers if they are small enough.
>--
>Std-Proposals mailing list
>Std-Proposals_at_[hidden]
>https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>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.
Making these trivially copyable would be an ABI change, as they would get passed around in registers if they are small enough.
>--
>Std-Proposals mailing list
>Std-Proposals_at_[hidden]
>https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2024-05-17 07:40:23