-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
unsafe String constructors as free functions are inconsistent with design elsewhere #16708
Comments
The non-static |
thestinger
changed the title
unsafe String constructors are inconsistent with design elsewhere
unsafe String constructors as free functions are inconsistent with design elsewhere
Aug 23, 2014
cc me |
Not 1.0, P-backcompat-lang. |
Closing; this has been addressed. |
matthiaskrgr
pushed a commit
to matthiaskrgr/rust
that referenced
this issue
Mar 10, 2024
internal: Move ide-assists codegen tests into an xtask codegen command
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In the past we agreed to get rid of these
unsafe
functions and replace them with static methods, but they've come back on strings and the previous methods are marked as deprecated. AFAIK, this did not go through an RFC, and is inconsistent with the design used elsewhere in the standard library based on the strong consensus in the previous discussions on the mailing list and issue tracker. For example,from_raw_parts
is a method onVec
and was a method onString
but has been deprecated.Static methods play very well with Rust's import system, because it allows accessing all of the methods via the scope. It's already marked
unsafe
, and going out of the way to makeunsafe
code painful just makes the language lose appeal as a systems language.The parameters also shifted around in
from_parts
relative tofrom_raw_parts
on Vec and String, so even that part of the design is inconsistent withVec<T>
.The text was updated successfully, but these errors were encountered: