Skip to content
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

Add a loop-iterator for option (suggest better names) #2927

Closed
bblum opened this issue Jul 16, 2012 · 5 comments
Closed

Add a loop-iterator for option (suggest better names) #2927

bblum opened this issue Jul 16, 2012 · 5 comments
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@bblum
Copy link
Contributor

bblum commented Jul 16, 2012

I found myself wanting this a lot during ICFP (#2928):

fn sequence<T>(+x: option<T>, blk: fn(+T) -> option<T>) {
    if x.is_some() {
        sequence(blk(option::unwrap(x)), blk)
    }   
}

impl iteration<T: copy> for option<T> {
    fn sequence(blk: fn(+T) -> option<T>) {
        if self.is_some() {
            blk(self.get()).sequence(blk)
        }   
    }   
}

(It would have to be written non-tail-recursively, for non-optimised builds to be able to infinite loop with it, but the tail recursive way is so much prettier.)

As it is, option::iter is just a special case of option::map where the return type of the block is unit. No need for it to be a different function.

@ghost ghost assigned bblum Jul 16, 2012
@nikomatsakis
Copy link
Contributor

The naming of option::iter is consistent with e.g. vec::iter. I think what you are describing here is actually chain.

@nikomatsakis
Copy link
Contributor

Oh, I see, your version of iterate reaches a fixed point, so no, it's not chain, but I think it's also not what option::iter ought to do...

@bblum bblum reopened this Jul 16, 2012
@bblum
Copy link
Contributor Author

bblum commented Jul 16, 2012

Yeah, I was looking at chain, too. Chain only recurses once, though - the point of this is to enable writing loops.

I wanted to call it chain more than I want to call it iterate; do suggest better names if you can think of any.

@nikomatsakis
Copy link
Contributor

apply_until_none?

@bblum
Copy link
Contributor Author

bblum commented Jul 16, 2012

It's not as snappy... maybe sequence? My original thought was while_some (and I wondered if while_none would ever be useful).

I'd say change chain to bind or link, but that would break existing code because they have compatible type signatures but different semantics...

@bblum bblum closed this as completed in bc87e66 Jul 17, 2012
@bblum bblum removed their assignment Jun 16, 2014
flip1995 pushed a commit to flip1995/rust that referenced this issue May 27, 2020
Register redundant_field_names and non_expressive_names as early passes

Similar names was moved to a pre-expansion pass to solve rust-lang#2927, so I'm avoiding linting on code from expansion, which makes the dogfood (mostly, see below) pass.

I had to change new_without_default though, and although I understand why it was not triggering before, TBH I don't see why the binding inside the nested `if_chain` is being linted now. Any ideas? (it seems legit though as the code can be changed by the user)

changelog: Register redundant_field_names and non_expressive_names as early passes

Fixes rust-lang#5356
Fixes rust-lang#5521
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Development

No branches or pull requests

2 participants