Is the WTF-8 stringview really needed? Could it be dropped from the MVP, or, could its functionality be folded into the general stringref facility, or the WTF-8 functionality of the general stringref facility moved to the WTF-8 view?
The use case for stringview_wtf8 is a language that wants to represent strings as UTF-8 / WTF-8, for example Rust. Though we expect the initial implementation of stringref support in Rust to be an eager copy/encode to UTF-8 on the boundaries, we can imageine that over time we'd see a desire to optimize specific interfaces to avoid a copy. So for example you would might implement a prefix check as "compare the first 10 WTF-8 bytes to this UTF-8 sequence, which I already have in main memory because I'm Rust and that's how I like to do things".
It could be that this use case is important and that stringview_wtf8 is appropriate. To decide this question we'll see about implementation feedback, and we will need to get feedback from WTF-8 language users.
Is the WTF-8 stringview really needed? Could it be dropped from the MVP, or, could its functionality be folded into the general stringref facility, or the WTF-8 functionality of the general stringref facility moved to the WTF-8 view?
The use case for
stringview_wtf8is a language that wants to represent strings as UTF-8 / WTF-8, for example Rust. Though we expect the initial implementation ofstringrefsupport in Rust to be an eager copy/encode to UTF-8 on the boundaries, we can imageine that over time we'd see a desire to optimize specific interfaces to avoid a copy. So for example you would might implement a prefix check as "compare the first 10 WTF-8 bytes to this UTF-8 sequence, which I already have in main memory because I'm Rust and that's how I like to do things".It could be that this use case is important and that
stringview_wtf8is appropriate. To decide this question we'll see about implementation feedback, and we will need to get feedback from WTF-8 language users.