add is_sorted, is_sorted_by, is_sorted_by_key

[gnzlbg]

No description provided.

[gnzlbg]

@bluss looks like rand made a breaking change but did not bump the major semver version :(

[scottmcm]

For a while-let with an early return, should this be &mut self instead, like all and any?

(nit: can it be written in terms of all, until try_fold is stable?)

[gnzlbg]

I'll give these a try!

[gnzlbg]

@scottmcm these should be fixed now

[gnzlbg]

@scottmcm probably the solution to fixing the travis bots is to raise the minimum version of stable supported, or to disable tests that don't work on the stable version used. Bumping the minimum version of stable supported will require a major semver bump though (0.7 to 0.8).

[bluss]

sad to see rand breaking that

[bluss]

Hi, it looks good. Please place these new methods in the regular method section. For example after the sorted methods.

[gnzlbg]

I've moved the methods. Is that place ok? I did not realize the methods were separated into sections :/

[bluss]

It's in the Itertools trait doc, but it's impossible to see that doc due to the big ugly code block that starts a trait documentation page.

[bluss]

The trait Itertools: extra iterator adaptors and methods for iterators.

This trait defines a number of methods. They are divided into two groups:

Adaptors take an iterator and parameter as input, and return a new iterator value. These are listed first in the trait. An example of an adaptor is .interleave()

Regular methods are those that don't return iterators and instead return a regular value of some other kind. .next_tuple() is an example and the first regular method in the list.

[bluss]

Thanks. We need to see how the discussion for std is going. As witnessed with the flatten problems, it would suck to introduce these here only to have them in std shortly afterwards.

[gnzlbg]

No worries, I have my own fork of itertools in the meantime and I can migrate to nightly if these are incuded in std in the mean time. I just wanted to upstream these here to show exactly which implementation I was proposing in the Rust-Lang issue. There were some questions about making these free functions instead but I still do think that making these Iterator methods is the most flexible approach.

…

On Sun 4. Mar 2018 at 16:14, bluss ***@***.***> wrote: Thanks. We need to see how the discussion for std is going. As witnessed with the flatten problems, it would suck to introduce these here only to have them in std shortly afterwards. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#261 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA3Npl-UE4nhG_i86ywiRHUMTuwGEzYxks5tbATvgaJpZM4R6DN2> .

[bluss]

Superseded by work in std, rust-lang/rust/pull/55045

[oxalica]

Superseded by work in std, rust-lang/rust/pull/55045

It's 2 years but still not stable. Couldn't we also impl these methods in itertools as stable alternatives?