New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for Iterator::try_fold and try_rfold (feature iterator_try_fold) #45594

Closed
scottmcm opened this Issue Oct 28, 2017 · 17 comments

Comments

Projects
None yet
10 participants
@scottmcm
Member

scottmcm commented Oct 28, 2017

The core internal iteration methods in terms of which the other Iterator methods can be implemented.

PR #45595, commit b32267f -- merged 2017-11-17
https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html#method.try_fold
https://doc.rust-lang.org/nightly/std/iter/trait.DoubleEndedIterator.html#method.try_rfold

Also try_for_each (PR #48157, merged 2018-02-24), a convenience method that can be considered the fallible version of for_each or the stateless version of try_fold.
https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html#method.try_for_each

Pre-stabilization question list:

@leonardo-m

This comment has been minimized.

Show comment
Hide comment
@leonardo-m

leonardo-m commented Oct 28, 2017

Is this usable to implement a fold1?

http://zvon.org/other/haskell/Outputprelude/foldl1_f.html

@bluss

This comment has been minimized.

Show comment
Hide comment
@bluss

bluss Oct 28, 2017

Contributor

There's already a fold1 in itertools and its implementation is quite simple:

    fn fold1<F>(mut self, f: F) -> Option<Self::Item>
        where F: FnMut(Self::Item, Self::Item) -> Self::Item,
              Self: Sized,
    {
        self.next().map(move |x| self.fold(x, f))
    }

The major difference to haskell foldl1 is that itertools fold1 returns an Option, with None for when the iterator is empty, instead of a runtime error like in Haskell.

Contributor

bluss commented Oct 28, 2017

There's already a fold1 in itertools and its implementation is quite simple:

    fn fold1<F>(mut self, f: F) -> Option<Self::Item>
        where F: FnMut(Self::Item, Self::Item) -> Self::Item,
              Self: Sized,
    {
        self.next().map(move |x| self.fold(x, f))
    }

The major difference to haskell foldl1 is that itertools fold1 returns an Option, with None for when the iterator is empty, instead of a runtime error like in Haskell.

@scottmcm

This comment has been minimized.

Show comment
Hide comment
@scottmcm

scottmcm Oct 29, 2017

Member

That same technique is also used for the min & max methods on Iterator: https://github.com/rust-lang/rust/pull/45595/files#diff-1398f322bc563592215b583e9b0ba936R2360

Member

scottmcm commented Oct 29, 2017

That same technique is also used for the min & max methods on Iterator: https://github.com/rust-lang/rust/pull/45595/files#diff-1398f322bc563592215b583e9b0ba936R2360

@cuviper

This comment has been minimized.

Show comment
Hide comment
@cuviper

cuviper Nov 8, 2017

Member

I think try_rfold should conceptually depend on stabilizing rfold first -- #44705.
(even though the default implementation goes the other way, rfold calling try_rfold)

Member

cuviper commented Nov 8, 2017

I think try_rfold should conceptually depend on stabilizing rfold first -- #44705.
(even though the default implementation goes the other way, rfold calling try_rfold)

@scottmcm

This comment has been minimized.

Show comment
Hide comment
@scottmcm

scottmcm Nov 8, 2017

Member

Well, rfold is already in the current beta, so it could probably be proposed for stabilization in 1.23...

Member

scottmcm commented Nov 8, 2017

Well, rfold is already in the current beta, so it could probably be proposed for stabilization in 1.23...

@cramertj

This comment has been minimized.

Show comment
Hide comment
@cramertj

cramertj Jan 4, 2018

Member

I wound up writing some code that really wanted try_filter_map (return a Result<Option<T>> instead of just Option<T>), and instead wound up doing something like .map(|x| x.to_res_opt()).try_filter_map(res_opt_to_opt_res). I wound up opening this PR as a result, which allows you to use Into to get the res_opt_to_opt_res behavior, however I still think built-in try_xxxs are more straightforward (I could see try_filter, try_filter_map, try_scan, try_inspect, etc... all being handy). I'm not sure how far we should take this before we just say to write a dang for loop 😜

Member

cramertj commented Jan 4, 2018

I wound up writing some code that really wanted try_filter_map (return a Result<Option<T>> instead of just Option<T>), and instead wound up doing something like .map(|x| x.to_res_opt()).try_filter_map(res_opt_to_opt_res). I wound up opening this PR as a result, which allows you to use Into to get the res_opt_to_opt_res behavior, however I still think built-in try_xxxs are more straightforward (I could see try_filter, try_filter_map, try_scan, try_inspect, etc... all being handy). I'm not sure how far we should take this before we just say to write a dang for loop 😜

Manishearth added a commit to Manishearth/rust that referenced this issue Feb 19, 2018

Rollup merge of rust-lang#48157 - scottmcm:try-for-each, r=dtolnay
Add Iterator::try_for_each

The fallible version of `for_each` aka the stateless version of `try_fold`.  Inspired by @cuviper's comment in rust-lang#45379 (comment) as a more direct and obvious solution than `.map(f).collect::<Result<(), _>>()`.

Like `for_each`, no need for an `r` version thanks to overrides in `Rev`.

`iterator_try_fold` tracking issue: rust-lang#45594

Manishearth added a commit to Manishearth/rust that referenced this issue Feb 19, 2018

Rollup merge of rust-lang#48157 - scottmcm:try-for-each, r=dtolnay
Add Iterator::try_for_each

The fallible version of `for_each` aka the stateless version of `try_fold`.  Inspired by @cuviper's comment in rust-lang#45379 (comment) as a more direct and obvious solution than `.map(f).collect::<Result<(), _>>()`.

Like `for_each`, no need for an `r` version thanks to overrides in `Rev`.

`iterator_try_fold` tracking issue: rust-lang#45594
@cuviper

This comment has been minimized.

Show comment
Hide comment
@cuviper

cuviper Feb 20, 2018

Member

Should we try to stabilize try_fold alone? (leaving try_rfold and try_for_each for later)

Member

cuviper commented Feb 20, 2018

Should we try to stabilize try_fold alone? (leaving try_rfold and try_for_each for later)

@SoniEx2

This comment has been minimized.

Show comment
Hide comment
@SoniEx2

SoniEx2 Feb 23, 2018

Why not try_fold into Iterator<R>? make it the opposite of flat_map!

SoniEx2 commented Feb 23, 2018

Why not try_fold into Iterator<R>? make it the opposite of flat_map!

Manishearth added a commit to Manishearth/rust that referenced this issue Feb 23, 2018

Rollup merge of rust-lang#48157 - scottmcm:try-for-each, r=dtolnay
Add Iterator::try_for_each

The fallible version of `for_each` aka the stateless version of `try_fold`.  Inspired by @cuviper's comment in rust-lang#45379 (comment) as a more direct and obvious solution than `.map(f).collect::<Result<(), _>>()`.

Like `for_each`, no need for an `r` version thanks to overrides in `Rev`.

`iterator_try_fold` tracking issue: rust-lang#45594
@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Mar 17, 2018

Contributor

Are these the best type parameters? #45462

In a perfect world the two signatures would be equivalent, but the code that landed already uses the formulation that works better with inference so I think it’s better to keep it that way.

Stabilize rfold before try_rfold?
Stabilize try_fold before the others?

Let’s stabilize them all together? :)

@rfcbot fcp merge

As of today try_for_each has only been in Nightly for 21 days, but at the soonest it will reach the Stable channel in 1.26 on May 11 after almost three months. More likely in 1.27 after over 4 months.

Contributor

SimonSapin commented Mar 17, 2018

Are these the best type parameters? #45462

In a perfect world the two signatures would be equivalent, but the code that landed already uses the formulation that works better with inference so I think it’s better to keep it that way.

Stabilize rfold before try_rfold?
Stabilize try_fold before the others?

Let’s stabilize them all together? :)

@rfcbot fcp merge

As of today try_for_each has only been in Nightly for 21 days, but at the soonest it will reach the Stable channel in 1.26 on May 11 after almost three months. More likely in 1.27 after over 4 months.

@scottmcm

This comment has been minimized.

Show comment
Hide comment
@scottmcm

scottmcm Mar 22, 2018

Member

@SimonSapin Looks like the rfcbot command didn't take. Does it need to be the first line?

Member

scottmcm commented Mar 22, 2018

@SimonSapin Looks like the rfcbot command didn't take. Does it need to be the first line?

@cramertj cramertj added the T-libs label Mar 22, 2018

@cramertj

This comment has been minimized.

Show comment
Hide comment
@cramertj

cramertj Mar 22, 2018

Member

@scottmcm The issue was missing a team tag :). @SimonSapin If you try again it should enter FCP (I cannot, as I am not on the libs team).

Member

cramertj commented Mar 22, 2018

@scottmcm The issue was missing a team tag :). @SimonSapin If you try again it should enter FCP (I cannot, as I am not on the libs team).

@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Mar 22, 2018

Contributor

Let’s try again:

@rfcbot fcp merge

Contributor

SimonSapin commented Mar 22, 2018

Let’s try again:

@rfcbot fcp merge

@rfcbot

This comment has been minimized.

Show comment
Hide comment
@rfcbot

rfcbot Mar 22, 2018

Team member @SimonSapin has proposed to merge this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

rfcbot commented Mar 22, 2018

Team member @SimonSapin has proposed to merge this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rfcbot

This comment has been minimized.

Show comment
Hide comment
@rfcbot

rfcbot Mar 22, 2018

🔔 This is now entering its final comment period, as per the review above. 🔔

rfcbot commented Mar 22, 2018

🔔 This is now entering its final comment period, as per the review above. 🔔

@ExpHP

This comment has been minimized.

Show comment
Hide comment
@ExpHP

ExpHP Mar 24, 2018

Contributor

To be clear, this is stabilizing before the Try trait?

This completely slipped by me even though I desperately wish for it all the time, as I never would've figured that functions involving Try would be receiving stabilization yet. I hope we've gained enough experience using these to validate their utility?


Note: I know this is not unheard of; consider the Sum trait. However, Sum was a hack to get one very small (but important) function working. These functions, on the other hand, could see pretty wide use all over a codebase, and they set precedents for best practices involving Try. Best make sure they're up to snuff!

Contributor

ExpHP commented Mar 24, 2018

To be clear, this is stabilizing before the Try trait?

This completely slipped by me even though I desperately wish for it all the time, as I never would've figured that functions involving Try would be receiving stabilization yet. I hope we've gained enough experience using these to validate their utility?


Note: I know this is not unheard of; consider the Sum trait. However, Sum was a hack to get one very small (but important) function working. These functions, on the other hand, could see pretty wide use all over a codebase, and they set precedents for best practices involving Try. Best make sure they're up to snuff!

@scottmcm

This comment has been minimized.

Show comment
Hide comment
@scottmcm

scottmcm Mar 25, 2018

Member

Yes, this is stabilizing before the Try trait.

That doesn't scare me on the flexibility side because, no matter how the Try trait changes, they have the same needs as ? and catch: get the value with which to continue, and turn that back into the fallible type.

On the consumption side, I'm not worried because this is basically the same as itertools's fold_results and fold_options merged into one via the trait, since those are the only two types that can actually be used with it for now anyway. (And it's also fold_while once you can make the type to make it nicer on stable.)

They've also been discussed for a while as core internal iteration methods, though those wins are only available to stdlib types until the Try trait stabilizes too.

Now, one could argue that try_for_each isn't really needed, but that was the case for for_each as well for a long time, so I think just having it is fine.

Member

scottmcm commented Mar 25, 2018

Yes, this is stabilizing before the Try trait.

That doesn't scare me on the flexibility side because, no matter how the Try trait changes, they have the same needs as ? and catch: get the value with which to continue, and turn that back into the fallible type.

On the consumption side, I'm not worried because this is basically the same as itertools's fold_results and fold_options merged into one via the trait, since those are the only two types that can actually be used with it for now anyway. (And it's also fold_while once you can make the type to make it nicer on stable.)

They've also been discussed for a while as core internal iteration methods, though those wins are only available to stdlib types until the Try trait stabilizes too.

Now, one could argue that try_for_each isn't really needed, but that was the case for for_each as well for a long time, so I think just having it is fine.

@rfcbot

This comment has been minimized.

Show comment
Hide comment
@rfcbot

rfcbot Apr 1, 2018

The final comment period is now complete.

rfcbot commented Apr 1, 2018

The final comment period is now complete.

kennytm added a commit to kennytm/rust that referenced this issue Apr 4, 2018

Rollup merge of rust-lang#49607 - cuviper:stable-iter-1.27, r=alexcri…
…chton

Stabilize iterator methods in 1.27

- Closes rust-lang#39480, feature  `iter_rfind`
  - `DoubleEndedIterator::rfind`
- Closes rust-lang#44705, feature `iter_rfold`
  - `DoubleEndedIterator::rfold`
- Closes rust-lang#45594, feature `iterator_try_fold`
  - `Iterator::try_fold`
  - `Iterator::try_for_each`
  - `DoubleEndedIterator::try_rfold`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment