Date: Fri, 16 May 2025 21:15:01 +0200
On 16/05/2025 18.12, Hans Åberg via Std-Proposals wrote:
>
>> On 16 May 2025, at 14:20, Jan Schultke via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>> https://isocpp.org/files/papers/P3695R0.html will be in the next mailing.
>>
>> It seems like people almost universally dislike this implicit conversion, and overall, deprecation has been received very positively. However, I'd still be interested in your thoughts on this.
>
> One can have implicit conversions between the types std::string, std::u8string, and std::u32string, where std::u8string might guarantee valid UTF-8 sequences. Conversions from std::string would then throw exceptions for invalid UTF-8 sequences. No exceptions are needed for conversions between std::u8string and std::u32string.
These are conversion between library-defined class types,
which are totally unrelated to the three fundamental character
types discussed in P3695R0.
> Possibly, implicit conversions between char8_t and char32_t cause problems here.
How so? Why would the presence or absence of a conversion between T and U
affect the design space of supporting or not supporting a conversion between
some_class<T> to some_class<U>?
> So, removing them might be good as preparation for these strong conversions.
>
>> Furthermore, is anyone interested in helping me get some data on the blast radius of this deprecation? It's not so easy to mine this. Also, it would be nice if you had some experience regarding how this deprecation would impact your code base, if at all.
>
> I wrote some code doing such string conversions, on the link below. Having them implicit is imperative for migration to the types std::u8string and std::u32string from code that is only using std::string. It could be that it is useful checking the impact of having the implicit char-type conversion, though I haven't checked that.
>
> https://git.savannah.gnu.org/cgit/metalogic-inference.git/tree/src/utf.hh
Jens
>
>> On 16 May 2025, at 14:20, Jan Schultke via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>> https://isocpp.org/files/papers/P3695R0.html will be in the next mailing.
>>
>> It seems like people almost universally dislike this implicit conversion, and overall, deprecation has been received very positively. However, I'd still be interested in your thoughts on this.
>
> One can have implicit conversions between the types std::string, std::u8string, and std::u32string, where std::u8string might guarantee valid UTF-8 sequences. Conversions from std::string would then throw exceptions for invalid UTF-8 sequences. No exceptions are needed for conversions between std::u8string and std::u32string.
These are conversion between library-defined class types,
which are totally unrelated to the three fundamental character
types discussed in P3695R0.
> Possibly, implicit conversions between char8_t and char32_t cause problems here.
How so? Why would the presence or absence of a conversion between T and U
affect the design space of supporting or not supporting a conversion between
some_class<T> to some_class<U>?
> So, removing them might be good as preparation for these strong conversions.
>
>> Furthermore, is anyone interested in helping me get some data on the blast radius of this deprecation? It's not so easy to mine this. Also, it would be nice if you had some experience regarding how this deprecation would impact your code base, if at all.
>
> I wrote some code doing such string conversions, on the link below. Having them implicit is imperative for migration to the types std::u8string and std::u32string from code that is only using std::string. It could be that it is useful checking the impact of having the implicit char-type conversion, though I haven't checked that.
>
> https://git.savannah.gnu.org/cgit/metalogic-inference.git/tree/src/utf.hh
Jens
Received on 2025-05-16 19:15:12