Date: Tue, 19 Jun 2018 13:03:00 +0000
Martinho Fernandes:
> As you said, there are many types out there that would support this
> concept, some of them already in the standard library. Why do I need a
> new one, and why would I use it instead of any of the other ones?
Because deducing std::basic_string as a code unit sequence for string
literals would be bringing an irrelevant broken legacy things such as
std::char_traits into otherwise extremely clean design.
I really really want C++ to show all other languages how proper Unicode
handling should be done. code_point_sequence<std::basic_string<...>>
would work absolutely fine for legacy codebases that can't migrate away
from std::basic_string. code_point_sequence_view<std::basic_string<...>>
would have no overhead too.
I've heard that there is work on a new allocator design too so having
std::allocator<std::byte> as default allocator is just a placeholder.
> As you said, there are many types out there that would support this
> concept, some of them already in the standard library. Why do I need a
> new one, and why would I use it instead of any of the other ones?
Because deducing std::basic_string as a code unit sequence for string
literals would be bringing an irrelevant broken legacy things such as
std::char_traits into otherwise extremely clean design.
I really really want C++ to show all other languages how proper Unicode
handling should be done. code_point_sequence<std::basic_string<...>>
would work absolutely fine for legacy codebases that can't migrate away
from std::basic_string. code_point_sequence_view<std::basic_string<...>>
would have no overhead too.
I've heard that there is work on a new allocator design too so having
std::allocator<std::byte> as default allocator is just a placeholder.
Received on 2018-06-19 15:04:06