Skip to content

Conversation

@erickt
Copy link
Contributor

@erickt erickt commented Sep 11, 2013

This is a series of patches to modernize option and result. The highlights are:

  • rename .unwrap_or_default(value) and etc to .unwrap_or(value)
  • add .unwrap_or_default() that uses the Default trait
  • add Default implementations for vecs, HashMap, Option
  • add Option.and(T) -> Option<T>, Option.and_then(&fn() -> Option<T>) -> Option<T>, Option.or(T) -> Option<T>, and Option.or_else(&fn() -> Option<T>) -> Option<T>
  • add option::ToOption, option::IntoOption, option::AsOption, result::ToResult, result::IntoResult, result::AsResult, either::ToEither, and either::IntoEither, either::AsEither
  • renamed Option::chain* and Result::chain* to and_then and or_else to avoid the eventual collision with Iterator.chain.
  • Added a bunch of impls of Default
  • Added a #[deriving(Default)] syntax extension
  • Removed impls of Zero for Option<T> and vecs.

@Kimundi
Copy link
Contributor

Kimundi commented Sep 11, 2013

It seems the docs for and_then and or_else are the same as and and or.
Maybe add a line to each explaining that the closure get's only run if the first value is Some/None?

Copy link
Contributor

Choose a reason for hiding this comment

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

Could you add a mention of this new one to the "deriving" section of the manual?

Copy link
Contributor

Choose a reason for hiding this comment

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

Is this x.or_default() different to Some(x.unwrap_or_default())? (Is it worth having a function just for this?)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Look at that. I added it because we already had .or_zero. I'll remove .or_default and .or_zero in a separate PR since this one is getting pretty weighty already.

@huonw
Copy link
Contributor

huonw commented Sep 13, 2013

This looks fine to me from a code point-of-view, but it feels like a significant addition of code that should be also approved by someone who's not me.

Also, cc #9157.

bors added a commit that referenced this pull request Sep 14, 2013
This is a series of patches to modernize option and result. The highlights are:

* rename `.unwrap_or_default(value)` and etc to `.unwrap_or(value)`
* add `.unwrap_or_default()` that uses the `Default` trait
* add `Default` implementations for vecs, HashMap, Option
* add  `Option.and(T) -> Option<T>`, `Option.and_then(&fn() -> Option<T>) -> Option<T>`, `Option.or(T) -> Option<T>`, and `Option.or_else(&fn() -> Option<T>) -> Option<T>`
* add `option::ToOption`, `option::IntoOption`, `option::AsOption`, `result::ToResult`, `result::IntoResult`, `result::AsResult`, `either::ToEither`, and `either::IntoEither`, `either::AsEither`
* renamed `Option::chain*` and `Result::chain*` to `and_then` and `or_else` to avoid the eventual collision with `Iterator.chain`.
* Added a bunch of impls of `Default`
* Added a `#[deriving(Default)]` syntax extension
* Removed impls of `Zero` for `Option<T>` and vecs.
@bors bors closed this Sep 14, 2013
flip1995 pushed a commit to flip1995/rust that referenced this pull request Jul 18, 2022
…logiq

`new_without_default`: ignore const generics/lifetime params on `fn new`

Fixes rust-lang#9113

No longer lints if `fn new` has any params

changelog: [`new_without_default`]: no longer lints const generics and lifetime params on `fn new`
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