Skip to content

core: Apply stability attributes to ptr mod #14529

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

Merged
merged 1 commit into from
Jun 5, 2014
Merged

Conversation

brson
Copy link
Contributor

@brson brson commented May 30, 2014

This time we're not promoting anything directly to 'stable', but instead promoting functions we're happy with to 'unstable'. They'll become stable in another pass later.

  • null and mut_null are unstable. Their names may change if the unsafe
    pointer types change.
  • copy_memory and copy_overlapping_memory are unstable. We think they
    aren't going to change.
  • set_memory and zero_memory are experimental. Both the names and
    the semantics are under question.
  • swap and replace are unstable and probably won't change.
  • read is unstable, probably won't change
  • read_and_zero is experimental. It's necessity is in doubt.
  • mem::overwrite is now called ptr::write to match read and is
    unstable. mem::overwrite is now deprecated
  • array_each, array_each_with_len, buf_len, and position are
    all deprecated because they use old style iteration and their
    utility is generally under question.

Note that mem::overwrite, which was just declared stable last week, is deprecated now in favor of ptr::write. Woo!

@alexcrichton
Copy link
Member

Could you add some rationale to the #[unstable] attributes as well? This should also be tagged as a [breaking-change]

Otherwise r=me

@brson
Copy link
Contributor Author

brson commented May 30, 2014

@alexcrichton How is this breaking? No functions were changed.

@alexcrichton
Copy link
Member

Hm. Indeed.

@brson
Copy link
Contributor Author

brson commented May 30, 2014

I did add reasons to the null and mut_null functions, which are the only ones that we have questions about. The other unstable functions are all 'fine'.

* null and mut_null are unstable. Their names may change if the unsafe
  pointer types change.
* copy_memory and copy_overlapping_memory are unstable. We think they
  aren't going to change.
* set_memory and zero_memory are experimental. Both the names and
  the semantics are under question.
* swap and replace are unstable and probably won't change.
* read is unstable, probably won't change
* read_and_zero is experimental. It's necessity is in doubt.
* mem::overwrite is now called ptr::write to match read and is
  unstable. mem::overwrite is now deprecated
* array_each, array_each_with_len, buf_len, and position are
  all deprecated because they use old style iteration and their
  utility is generally under question.
bors added a commit that referenced this pull request Jun 5, 2014
This time we're not promoting anything directly to 'stable', but instead promoting functions we're happy with to 'unstable'. They'll become stable in another pass later.

* null and mut_null are unstable. Their names may change if the unsafe
  pointer types change.
* copy_memory and copy_overlapping_memory are unstable. We think they
  aren't going to change.
* set_memory and zero_memory are experimental. Both the names and
  the semantics are under question.
* swap and replace are unstable and probably won't change.
* read is unstable, probably won't change
* read_and_zero is experimental. It's necessity is in doubt.
* mem::overwrite is now called ptr::write to match read and is
  unstable. mem::overwrite is now deprecated
* array_each, array_each_with_len, buf_len, and position are
  all deprecated because they use old style iteration and their
  utility is generally under question.

Note that `mem::overwrite`, which was just declared stable last week, is deprecated now in favor of `ptr::write`. Woo!
@bors bors closed this Jun 5, 2014
@bors bors merged commit 9b228f8 into rust-lang:master Jun 5, 2014
flip1995 pushed a commit to flip1995/rust that referenced this pull request Apr 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants