Skip to content
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

core: Stabilize the mem module #14259

Merged
merged 1 commit into from
May 21, 2014
Merged

core: Stabilize the mem module #14259

merged 1 commit into from
May 21, 2014

Conversation

alexcrichton
Copy link
Member

Excluding the functions inherited from the cast module last week (with marked
stability levels), these functions received the following treatment.

  • size_of - this method has become #[stable]
  • nonzero_size_of/nonzero_size_of_val - these methods have been removed
  • min_align_of - this method is now #[stable]
  • pref_align_of - this method has been renamed without the
    pref_ prefix, and it is the "default alignment" now. This decision is in line
    with what clang does (see url linked in comment on function). This function
    is now #[stable].
  • init - renamed to zeroed and marked #[stable]
  • uninit - marked #[stable]
  • move_val_init - renamed to overwrite and marked #[stable]
  • {from,to}_{be,le}{16,32,64} - all functions marked #[stable]
  • swap/replace/drop - marked #[stable]
  • size_of_val/min_align_of_val/align_of_val - these functions are marked
    #[unstable], but will continue to exist in some form. Concerns have been
    raised about their _val prefix.

@lilyball
Copy link
Contributor

Why remove nonzero_size_of?

@alexcrichton
Copy link
Member Author

There are very few users of it, it doesn't have many applications, and it's very easy to make a wrapper for.

@huonw
Copy link
Member

huonw commented May 17, 2014

It's only used for Vec, which can just have its own implementation.

(Well, it's also used for ~[T], but no-one cares about that type ;P )

pub fn size_of<T>() -> uint {
unsafe { intrinsics::size_of::<T>() }
}

/// Returns the size of the type that `_val` points to in bytes.
#[inline]
#[stable]
pub fn size_of_val<T>(_val: &T) -> uint {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just thinking about it now, do we want to stabilise the abbreviated name size_of_val (rather than calling it size_of_value or some such)?

@alexcrichton
Copy link
Member Author

Pushed a commit with some re-wordings. I'd vote for val over value, but not very strongly.

@thestinger
Copy link
Contributor

@huonw: The only usage in vec.rs is for conversion to ~[T]. The Vec<T> implementation no longer allocates any memory for vectors of zero-size types, because I special-cased them early on to avoid needing to think about the various issues deeper in the code. The nonzero functions were a nice way of avoiding the need for special cases, but it was needlessly inefficient and it was hard to remember to use it everywhere along with avoiding offset.

@huonw
Copy link
Member

huonw commented May 18, 2014

@alexcrichton Would it be reasonable to not stabilise the ..._val functions for now, since I don't think those names were discussed explicitly?

@thestinger even better!

@alexcrichton
Copy link
Member Author

Good point! I've marked the *_val functions #[unstable] with a reason as to why, and updated the commit message/PR description.

@pcwalton
Copy link
Contributor

I thought the outcome of the meeting was that overwrite() wasn't going to be stable, since we weren't sure we loved the name.

@huonw
Copy link
Member

huonw commented May 20, 2014

Hm, shouldn't the old functions be there with a #[deprecated="renamed to ...] too?

@alexcrichton
Copy link
Member Author

Pushed with old functions brought back as #[deprecated] (thanks for the reminder @huonw!) and #[unstable] on uninit/overwrite/zeroed due to @pcwalton's comment.

I believe the idea is that we will revisit these names after getting some traction with them.

Excluding the functions inherited from the cast module last week (with marked
stability levels), these functions received the following treatment.

* size_of - this method has become #[stable]
* nonzero_size_of/nonzero_size_of_val - these methods have been removed
* min_align_of - this method is now #[stable]
* pref_align_of - this method has been renamed without the
  `pref_` prefix, and it is the "default alignment" now. This decision is in line
  with what clang does (see url linked in comment on function). This function
  is now #[stable].
* init - renamed to zeroed and marked #[stable]
* uninit - marked #[stable]
* move_val_init - renamed to overwrite and marked #[stable]
* {from,to}_{be,le}{16,32,64} - all functions marked #[stable]
* swap/replace/drop - marked #[stable]
* size_of_val/min_align_of_val/align_of_val - these functions are marked
  #[unstable], but will continue to exist in some form. Concerns have been
  raised about their `_val` prefix.

[breaking-change]
bors added a commit that referenced this pull request May 21, 2014
Excluding the functions inherited from the cast module last week (with marked
stability levels), these functions received the following treatment.

* size_of - this method has become #[stable]
* nonzero_size_of/nonzero_size_of_val - these methods have been removed
* min_align_of - this method is now #[stable]
* pref_align_of - this method has been renamed without the
  `pref_` prefix, and it is the "default alignment" now. This decision is in line
  with what clang does (see url linked in comment on function). This function
  is now #[stable].
* init - renamed to zeroed and marked #[stable]
* uninit - marked #[stable]
* move_val_init - renamed to overwrite and marked #[stable]
* {from,to}_{be,le}{16,32,64} - all functions marked #[stable]
* swap/replace/drop - marked #[stable]
* size_of_val/min_align_of_val/align_of_val - these functions are marked
  #[unstable], but will continue to exist in some form. Concerns have been
  raised about their `_val` prefix.
@bors bors closed this May 21, 2014
@bors bors merged commit 19dc3b5 into rust-lang:master May 21, 2014
@alexcrichton alexcrichton deleted the core-mem branch May 21, 2014 16:14
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.

6 participants