These are constructors for str, but they live in the core::str module. This means I always need a use core::str import in order to call them as str::from_utf8 (or fully qualify them).
I believe they could be made associated functions on the str type without breakage, the same way the integer constants where moved from modules to the primitive types.
I think this would make sense considering String::from_utf8 is an associated function.
however, this would break any code that has a different str::from_utf8 in scope if it re-imports the str primative after its own str module.
Personally I'd open a PR adding this. T-libs-api can then discuss as necessary.
I'd suggest starting with an ACP proposing the API.
the same applies to few fns from std::slice and std::ptr.
I would much rather write <[u8]>::from_raw_parts than use std::slice::from_raw_parts
For slice it's a matter of generic name; many people disagree and would prefer writing e.g. ptr::from_ref to <*const _>::from_ref that requires using the less familiar qualified paths syntax. slice:: is intended to read as if it were <[_]>:: with less symbol soup.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.