Generally positive, a few questions/doubts:
- Proposal says makeContiguous on non-contiguous will invalidate pre-existing indices. A major use-case of the API in this proposal is ensuring bridged Cocoa strings, that you need to do heavy-duty work on, are contiguous.
Typically when you work with Cocoa APIs, you also have some NSRange, or index that indicate a UTF-16 offset, that you need to convert to a String.Index. My question now is, when making a String contiguous from bridged Cocoa string, will the String also in the same pass build the UTF-16 "breadcrumbs" mentioned here: String’s ABI and UTF-8 ?
If not, I believe there should be an option to do so, or the following would seemingly be inefficient:
string.makeContiguous()
let range = Range(nsRange, in: string)
- Not sure if makeContigous operation on a Substring ever makes sense? If not already contiguous that would cause a copy. Isn't it better that such a copy is done explicitly?
let string = String(substring)
string.makeContigous()
- Wouldn't a (very) performance-minded user interested in getting direct access to the underlying code units usually want to:
- Check if the encoding UTF-8 -> access UTF-8 buffer
- Check if the encoding UTF-16 -> access UTF-16 buffer, and perhaps directly transcode to UTF-8 in a destination buffer