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

std: Fully stabilize Option<T> #19849

Merged
merged 1 commit into from
Dec 17, 2014
Merged

Conversation

alexcrichton
Copy link
Member

This commit takes a second pass through the std::option module to fully
stabilize any lingering methods inside of it.

These items were made stable as-is

  • Some
  • None
  • as_mut
  • expect
  • unwrap
  • unwrap_or
  • unwrap_or_else
  • map
  • map_or
  • map_or_else
  • and_then
  • or_else
  • unwrap_or_default
  • Default implementation
  • FromIterator implementation
  • Copy implementation

These items were made stable with modifications

  • iter - now returns a struct called Iter
  • iter_mut - now returns a struct called IterMut
  • into_iter - now returns a struct called IntoIter, Clone is never implemented

This is a breaking change due to the modifications to the names of the iterator
types returned. Code referencing the old names should updated to referencing the
newer names instead. This is also a breaking change due to the fact that
IntoIter no longer implements the Clone trait.

These items were explicitly not stabilized

  • as_slice - waiting on indexing conventions
  • as_mut_slice - waiting on conventions with as_slice as well
  • cloned - the API was still just recently added
  • ok_or - API remains experimental
  • ok_or_else - API remains experimental

[breaking-change]

This commit takes a second pass through the `std::option` module to fully
stabilize any lingering methods inside of it.

These items were made stable as-is

* Some
* None
* as_mut
* expect
* unwrap
* unwrap_or
* unwrap_or_else
* map
* map_or
* map_or_else
* and_then
* or_else
* unwrap_or_default
* Default implementation
* FromIterator implementation
* Copy implementation

These items were made stable with modifications

* iter - now returns a struct called Iter
* iter_mut - now returns a struct called IterMut
* into_iter - now returns a struct called IntoIter, Clone is never implemented

This is a breaking change due to the modifications to the names of the iterator
types returned. Code referencing the old names should updated to referencing the
newer names instead. This is also a breaking change due to the fact that
`IntoIter` no longer implements the `Clone` trait.

These items were explicitly not stabilized

* as_slice - waiting on indexing conventions
* as_mut_slice - waiting on conventions with as_slice as well
* cloned - the API was still just recently added
* ok_or - API remains experimental
* ok_or_else - API remains experimental

[breaking-change]
@@ -802,6 +801,66 @@ impl<A> DoubleEndedIterator<A> for Item<A> {

impl<A> ExactSizeIterator<A> for Item<A> {}

/// An iterator over a reference of the contained item in an Option.
#[stable]
pub struct Iter<'a, A: 'a> { inner: Item<&'a A> }
Copy link
Member

Choose a reason for hiding this comment

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

Isn't Item the "proper" name for this iterator according to the naming conventions RFC?

Copy link
Contributor

Choose a reason for hiding this comment

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

Can't find the right RFC for it, if it exists, but this has always been @aturon's intention for the names to become.

Copy link
Member Author

Choose a reason for hiding this comment

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

While Item used to be the conventional name, we've since tweaked the conventions so the name of the iterator returned should match the name of the method of iteration.

@@ -761,20 +764,16 @@ impl<T> AsSlice<T> for Option<T> {
#[stable]
impl<T> Default for Option<T> {
#[inline]
#[stable]
Copy link
Member

Choose a reason for hiding this comment

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

Just FYI, I don't believe the stability attributes on methods in trait impls have any meaning.

Copy link
Member

Choose a reason for hiding this comment

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

cc #14407 for why that doesn't warn.

bors referenced this pull request Dec 16, 2014
This creates an enormous amount of spew.
bors added a commit that referenced this pull request Dec 16, 2014
std: Fully stabilize Option<T>

Reviewed-by: aturon
bors referenced this pull request Dec 16, 2014
Using a type alias for iterator implementations is fragile since this
exposes the implementation to users of the iterator, and any changes
could break existing code.

This commit changes the iterators of `VecMap` to use
proper new types, rather than type aliases.  However, since it is
fair-game to treat a type-alias as the aliased type, this is a:

[breaking-change].
bors added a commit that referenced this pull request Dec 16, 2014
std: Fully stabilize Option<T>

Reviewed-by: aturon
brson added a commit that referenced this pull request Dec 16, 2014
This commit takes a second pass through the `std::option` module to fully
stabilize any lingering methods inside of it.

These items were made stable as-is

* Some
* None
* as_mut
* expect
* unwrap
* unwrap_or
* unwrap_or_else
* map
* map_or
* map_or_else
* and_then
* or_else
* unwrap_or_default
* Default implementation
* FromIterator implementation
* Copy implementation

These items were made stable with modifications

* iter - now returns a struct called Iter
* iter_mut - now returns a struct called IterMut
* into_iter - now returns a struct called IntoIter, Clone is never implemented

This is a breaking change due to the modifications to the names of the iterator
types returned. Code referencing the old names should updated to referencing the
newer names instead. This is also a breaking change due to the fact that
`IntoIter` no longer implements the `Clone` trait.

These items were explicitly not stabilized

* as_slice - waiting on indexing conventions
* as_mut_slice - waiting on conventions with as_slice as well
* cloned - the API was still just recently added
* ok_or - API remains experimental
* ok_or_else - API remains experimental

[breaking-change]
bors added a commit that referenced this pull request Dec 17, 2014
std: Fully stabilize Option<T>

Reviewed-by: aturon
alexcrichton added a commit to alexcrichton/rust that referenced this pull request Dec 17, 2014
This commit takes a second pass through the `std::option` module to fully
stabilize any lingering methods inside of it.

These items were made stable as-is

* Some
* None
* as_mut
* expect
* unwrap
* unwrap_or
* unwrap_or_else
* map
* map_or
* map_or_else
* and_then
* or_else
* unwrap_or_default
* Default implementation
* FromIterator implementation
* Copy implementation

These items were made stable with modifications

* iter - now returns a struct called Iter
* iter_mut - now returns a struct called IterMut
* into_iter - now returns a struct called IntoIter, Clone is never implemented

This is a breaking change due to the modifications to the names of the iterator
types returned. Code referencing the old names should updated to referencing the
newer names instead. This is also a breaking change due to the fact that
`IntoIter` no longer implements the `Clone` trait.

These items were explicitly not stabilized

* as_slice - waiting on indexing conventions
* as_mut_slice - waiting on conventions with as_slice as well
* cloned - the API was still just recently added
* ok_or - API remains experimental
* ok_or_else - API remains experimental

[breaking-change]
@alexcrichton
Copy link
Member Author

cc @jakub-

@alexcrichton
Copy link
Member Author

err sorry, wrong PR

@bors bors merged commit 1fbca88 into rust-lang:master Dec 17, 2014
@alexcrichton alexcrichton deleted the second-pass-option branch December 17, 2014 23:48
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.

5 participants