5 ms·

I don't think "fighting the compiler" is an accurate description of the Rust coding experience. There is a learning curve during which you feel like you fight t

I don't think "fighting the compiler" is an accurate description of the Rust coding experience. There is a learning curve during which you feel like you fight the borrow checker a lot, but once you get it you will find that the compiler is actually helpful.

duaneb 10y ago
Agreed. Refactoring tools would help address compiler concerns quicker, however.
deleted 10y ago
[deleted]
iopq 10y ago
There's plenty of fighting the compiler. error[E0281]: type mismatch: the type `fn(_) -> _ {tool::second::<_>}` implements the trait `std::ops::FnMut<(_,)>`, but the trait `for<'r> std::ops::FnMut<(&'r _,)>` is required (expected concrete lifetime, found bound lifetime parameter ) --> src\lib.rs:53:11 | 53 | .filter(apply(second, i)) | ^^^^^ | = note: required by `apply` error[E0271]: type mismatch resolving `for<'r> <fn(_) -> _ {tool::second::<_>} as std::ops::FnOnce<(&'r _,)>>::Output == _` --> src\lib.rs:53:11 | 53 | .filter(apply(second, i)) | ^^^^^ expected bound lifetime parameter , found concrete lifetime | = note: concrete lifetime that was found is lifetime '_#11r = note: required by `apply` error: aborting due to 2 previous errors I now know why I'm getting this error. Would you?
- vertex-four 10y ago
  Closure-related error messages are not one of the strong points of Rust so far, unfortunately.
- lmm 10y ago
  I suspect I would - I'll happily guess if I can take a look at the code (or at least the signatures of "filter", "apply", "second" and "i").
  - iopq 10y ago
    `i` is just getting closed over, it's an integer filter is from the standard lib apply is defined as fn apply<A, B, C, F, G>(mut f: F, a: A) -> impl FnMut(&B) -> C where F: FnMut(&B) -> G, G: FnMut(A) -> C, A: Clone { move |b| f(b)(a.clone()) } second comes from https://github.com/Stebalien/tool-rs/blob/master/src/sequence.rs#L30-L33 https://github.com/Stebalien/tool-rs/blob/master/src/sequenc... which means you have to track down its implementation somewhere in macros
  - iopq 10y ago
    I put the whole code in a separate branch for you: https://bitbucket.org/iopq/fizzbuzz-in-rust/src/920bd2bd1267d4bb495d114db6dbf396106962d4/src/lib.rs?at=error&fileviewer=file-view-default https://bitbucket.org/iopq/fizzbuzz-in-rust/src/920bd2bd1267... this doesn't work, so I want you to tell me why
    - lmm 10y ago
      Hmm fair enough, harder than I thought (I don't know Rust, the error just sounded sensible). It reads like the function you're passing into filter is supposed to be "lifetime-generic" taking a parameter whose lifetime comes from the for, but the function returned by apply has a fixed lifetime. But I can't see where it's getting the lifetime for that from, or what to do about it. I guess at that point I'd try adding an explicit lifetime to the return type of apply (or maybe an IDE could show it without having to write it)?
      - iopq 10y ago
        The problem is with the function `second` that I get from the other crate. If I replace the `second` function with my own implementation it works. But for the `second` implementation from tool.rs to work, Rust needs better higher ranked lifetime support. It would also work with a closure, but I wrote my code this way to avoid closures in the first place (I was going for point-free style). I basically just have to write my own function: https://bitbucket.org/iopq/fizzbuzz-in-rust/src/58bfa4c58c803b04451ae60fe06da4450aef9658/src/lib.rs?at=master&fileviewer=file-view-default#lib.rs-66:68 https://bitbucket.org/iopq/fizzbuzz-in-rust/src/58bfa4c58c80... this compiles, but it seems kind of pointless since I can only use this particular function in my case (because of the extra levels of references) if I could use the tool.rs version, it would automatically generate all the implementations I need using macros
- pcwalton 10y ago
  That's a bad error message. Please file a bug :) It sounds like you're returning closures, which is a very recent feature—it only became possible last month with the implementation of "impl Trait" IIRC. It takes time for features to mature.
  - iopq 10y ago
    https://github.com/rust-lang/rust/issues/37300 https://github.com/rust-lang/rust/issues/37300
annnnd 10y ago
Either that, or the Stockholm sindrom kicks in after a while. :)

duaneb 10y ago

Agreed. Refactoring tools would help address compiler concerns quicker, however.

deleted 10y ago

[deleted]

iopq 10y ago

There's plenty of fighting the compiler. error[E0281]: type mismatch: the type `fn(_) -> _ {tool::second::<_>}` implements the trait `std::ops::FnMut<(_,)>`, but the trait `for<'r> std::ops::FnMut<(&'r _,)>` is required (expected concrete lifetime, found bound lifetime parameter ) --> src\lib.rs:53:11 | 53 | .filter(apply(second, i)) | ^^^^^ | = note: required by `apply` error[E0271]: type mismatch resolving `for<'r> <fn(_) -> _ {tool::second::<_>} as std::ops::FnOnce<(&'r _,)>>::Output == _` --> src\lib.rs:53:11 | 53 | .filter(apply(second, i)) | ^^^^^ expected bound lifetime parameter , found concrete lifetime | = note: concrete lifetime that was found is lifetime '_#11r = note: required by `apply` error: aborting due to 2 previous errors I now know why I'm getting this error. Would you?

vertex-four 10y ago
Closure-related error messages are not one of the strong points of Rust so far, unfortunately.
lmm 10y ago
I suspect I would - I'll happily guess if I can take a look at the code (or at least the signatures of "filter", "apply", "second" and "i").
- iopq 10y ago
  `i` is just getting closed over, it's an integer filter is from the standard lib apply is defined as fn apply<A, B, C, F, G>(mut f: F, a: A) -> impl FnMut(&B) -> C where F: FnMut(&B) -> G, G: FnMut(A) -> C, A: Clone { move |b| f(b)(a.clone()) } second comes from https://github.com/Stebalien/tool-rs/blob/master/src/sequence.rs#L30-L33 https://github.com/Stebalien/tool-rs/blob/master/src/sequenc... which means you have to track down its implementation somewhere in macros
- iopq 10y ago
  I put the whole code in a separate branch for you: https://bitbucket.org/iopq/fizzbuzz-in-rust/src/920bd2bd1267d4bb495d114db6dbf396106962d4/src/lib.rs?at=error&fileviewer=file-view-default https://bitbucket.org/iopq/fizzbuzz-in-rust/src/920bd2bd1267... this doesn't work, so I want you to tell me why
  - lmm 10y ago
    Hmm fair enough, harder than I thought (I don't know Rust, the error just sounded sensible). It reads like the function you're passing into filter is supposed to be "lifetime-generic" taking a parameter whose lifetime comes from the for, but the function returned by apply has a fixed lifetime. But I can't see where it's getting the lifetime for that from, or what to do about it. I guess at that point I'd try adding an explicit lifetime to the return type of apply (or maybe an IDE could show it without having to write it)?
    - iopq 10y ago
      The problem is with the function `second` that I get from the other crate. If I replace the `second` function with my own implementation it works. But for the `second` implementation from tool.rs to work, Rust needs better higher ranked lifetime support. It would also work with a closure, but I wrote my code this way to avoid closures in the first place (I was going for point-free style). I basically just have to write my own function: https://bitbucket.org/iopq/fizzbuzz-in-rust/src/58bfa4c58c803b04451ae60fe06da4450aef9658/src/lib.rs?at=master&fileviewer=file-view-default#lib.rs-66:68 https://bitbucket.org/iopq/fizzbuzz-in-rust/src/58bfa4c58c80... this compiles, but it seems kind of pointless since I can only use this particular function in my case (because of the extra levels of references) if I could use the tool.rs version, it would automatically generate all the implementations I need using macros
pcwalton 10y ago
That's a bad error message. Please file a bug :) It sounds like you're returning closures, which is a very recent feature—it only became possible last month with the implementation of "impl Trait" IIRC. It takes time for features to mature.
- iopq 10y ago
  https://github.com/rust-lang/rust/issues/37300 https://github.com/rust-lang/rust/issues/37300

annnnd 10y ago

Either that, or the Stockholm sindrom kicks in after a while. :)