Okay, might have misread your post.

I agree with the basic premise, we should not be introducing branches into the code if we know the endian at compile time.

-------- Original Message --------
On Mar 5, 2020, 18:49, Ryan Nicholl wrote:

> Endian is usually a system architecture thing. I don't know any systems with runtime endianness.
> -------- Original Message --------
> On Mar 5, 2020, 17:27, Maciej Cencora via Std-Proposals wrote:
>
>> Unless I am missing something the endianness is a runtime property.
>> You should provide API that allow to serialize based on compile-time provided endianess (either two functions different names, or templated by endianess), as I do not want to pay the prize of runtime dispatch overhead (+unnecessary code bloat) in scenarios where endianess is known up-front.
>>
>> Regards,
>> Maciej
>>
>> czw., 5 mar 2020 o 20:38 Lyberta via Std-Proposals <std-proposals_at_[hidden]> napisał(a):
>>
>>> This paper proposes fundamental IO concepts, customization points for serialization and deserialization and streams for memory
>>> and file IO.
>>>
>>> It was initially based on design similar to iostreams but most of it was changed to be in line with modern C++20 practice. In
>>> particular, the proposal embraces type erasure instead of virtual functions, exceptions instead of operator bool() and
>>> customization points instead of arithmetic shift operators.
>>>
>>> During benchmarking of sequential file IO on Linux proposed std::io::input_file_stream is ~30% faster than std::FILE and ~45%
>>> faster than std::ifstream while proposed std::io::output_file_stream is ~38% faster than std::FILE and ~60% faster than
>>> std::ofstream.
>>>
>>> I'm looking for a champion to present the proposal in Varna.
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_lists.isocpp.org
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals