std: Second pass stabilization of Result<T, E>

[alexcrichton]

This commit, like the second pass of Option, largely just stablizes the
existing functionality after renaming a few iterators.

The specific actions taken were:

• The Ok and Err variants were marked #[stable] as the stability
  inheritance was since removed.
• The as_mut method is now stable.
• The map method is now stable
• The map_err method is now stable
• The iter, iter_mut, and into_iter methods now returned structures named
  after the method of iteration. The methods are also now all stable.
• The and_then method is now stable.
• The or_else method is now stable.
• The unwrap family of functions are now all stable: unwrap_or,
  unwrap_or_else, unwrap, and unwrap_err.

There is a possible open extension to Result::{and, and_then} to make the
return type further generic over FromError (as proposed in #19078), but this
is a backwards compatible change due to the usage of default type parameters,
which makes the two functions safe to stabilize now regardless of the outcome of
that issue.

[alexcrichton]

r? @aturon

[alexcrichton]

cc @jakub-

[steveklabnik]

This reads weird. Is that first 'a' needed?

[alexcrichton]

Good point! Reworded slightly with a pushed update.

[tbu-]

@alexcrichton This is only backwards-compatible if the code has specified the Result good enough, otherwise the inference could stop to work.

[alexcrichton]

@tbu- can you elaborate? I'm not sure I understand what you mean sadly :(

[tbu-]

The current signature of and in Result<T,E> is:

fn and<U>(self, res: Result<U, E>) -> Result<U, E>;

If this is changed to

fn and<U,F:FromError<E>>(self, res: Result<U, F>) -> Result<U,F>;

then the type of the parameter is less constrained. In particular one can see in the pull request you linked that additional type annotations were needed in the tests of this new and function.

[alexcrichton]

Ah the PR actually recommended a signature like:

fn and<U,F:FromError<E>=E>(self, res: Result<U, F>) -> Result<U,F>;

which with the default type parameter I believe makes it a backwards-compatible change.

[reem]

I actually do not think that it is wise to bake FromError into the basic operations surrounding Result, since it makes these ubiquitous ops only usable for errors, not for other uses of Result as a stop-gap for Either.

[tbu-]

@alexcrichton Yeah, you're right, with the default type parameter this looks backwards-compatible.