23 ms·
Since it's not a breaking change it's not coming in 1.0, probably shortly after it though.
by arthursilva 12y ago
Since it's not a breaking change it's not coming in 1.0, probably shortly after it though.
- kzrdude 12y agoit looks like a breaking change, say if you change the return type of `fn iter()` on a slice.
- arthursilva 12y agoIt seems to me it's inference so the type will stay the same, just inferred.
- kibwen 12y agoIt actually does have the potential to break things, because to do this today requires you to explicitly list out all the types of the return type (which should really be considered implementation details). If a user of your function accidentally relies on one of these details, their code would be broken once you switch from the fully-specified return type to an anonymized return type.
- arthursilva 12y agoWell, if you take advantage of it may break stuff. Although this doesn't really qualify as a breaking change since older code is going to compile when it's introduced.
- kzrdude 12y agoOlder code that uses specific features of that iterator will break. The slice iterator has its own methods (turn it into a slice), it's clonable and it is Copy.
- Gankro 12y agoIt's only a breaking change to one's API to actually use the functionality, though. I don't think there's anywhere in std's public APIs where we would suddenly change from returning a concrete iterator to an "abstract" one.