std: Mark the IntoIterator trait as stable

[alexcrichton]

This commit marks the trait IntoIterator as well as the associated type Iter
and method into_iter all as stable.

This also fixes up some missing stability on some other assorted traits.

[rust-highfive]

r? @pcwalton

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

r? @aturon

[aturon]

I have two worries here.

First, I think the Iter associated type should probably be called IntoIter to match conventions. I realize that may be confusing, but consider what will happen if we later introduce an Iter trait.

Second, I think we may want to add an Item associated type:

pub trait IntoIterator {
    type Item;
    type Iter: Iterator<Item = Self::Item>;
    ...
}

That will make it much easier to bound over the item type of the trait. It imposes a slight ergonomic burden on implementors, but once default associated types land we should be able to remove that burden.

cc @japaric

[Gankra]

Is stabalizing these not a bit premature? We litterally just landed them.

[japaric]

Second, I think we may want to add an Item associated type:

Sounds good to me, since you almost always want to bind Iter::Item, and not Iter. With the current definition the best we could write in the future is I: IntoIterator, I::Iter::Item: Str and I: IntoIterator, I::Iter: Iterator<Item=u8>. Whereas the proposed change would let us write I: IntoIterator, I::Item: Str (1) and I: IntoIterator<Item=u8>.

(1) (I wonder if we could allow I: IntoIterator<Item: Str> as a short-hand for I: IntoIterator, I::Item: Str? Or is that too crazy?)

It imposes a slight ergonomic burden on implementors, but once default associated types land we should be able to remove that burden.

Yes, I think that default type params would let us remove type Item = Foo from the implementations.

I think the Iter associated type should probably be called IntoIter

If we are going to add type Item, then I'm not going to oppose to changing the name of Iter, as it won't be used in most cases (i.e. in assoc type bindings), just in the implementations.

[alexcrichton]

Ok, I've moved the missing stability attributes to #21870 and otherwise the desired definition of IntoIterator cannot currently be written due to #20220. As a result I'm going to close this for now.

Is stabalizing these not a bit premature? We litterally just landed them.

I agree that these haven't been around for awhile, but this also means that you cannot use a for loop without #![feature(core)] which seems like a bit of a regression to me...