7 ms·

I wonder if I would ever find something like my_iter .foo() .bar() .return more appealing than return my_iter .foo()

• nixpulvis 7y ago
  See, now this is exactly my issue with this syntax, I generally expect to be able to "chain" things with the "." notation.
  • mintplant 7y ago
    You can chain .await, though. let n = future_of_future_of_int .await .await;
    • asdkhadsj 7y ago
      Curiously, will there be limitations to where it can be used? Eg, imagine a `foos.iter().map(|f| f.await).collect::<Vec<_>>()`? That seems crazy, think it'll be possible?
      • comex 7y ago
        Not as things are currently designed. This is similar to how you can’t use things like the `?` operator, break, return, etc. inside a lambda and expect it to affect the outer function: it doesn’t work because lambdas are treated as their own functions. Personally I think it would be cool to pursue an extension to lambdas that would allow some of those things to work, but I’m not a Rust team member or anything, just an interested observer.
        • swsieber 7y ago
          Technically, `?` can work in lambda's if the return value is a `Result` - though it won't work like it's being called as part of a normal loop or whatever. That's largely mitigated by the combinators available on an interator of `Result`s. So I think we'll just need similar tooling for lambdas - perhaps an `async` modifier for them? That (I think) would lift await stuff up to `?` in terms of lambda support.
          • comex 7y ago
            Yep, and in fact async lambdas are already a thing on nightly. But, while I may just be nitpicking, `.map(async |f| f.await)` wouldn't do anything useful. Applied to an Iterator of Futures, it would be a no-op, kind of like (since you mentioned `?`) `.map(|x| Ok(x?)). Instead you'd probably want some combinator to turn it into whatever "Iterator but async" trait Rust eventually standardizes on – futures-rs has Stream for this purpose, but std doesn't have anything yet. That trait would have its own collect() method which would return a Future<Output=Vec<T>>, and you'd then await on that. Yeah, I guess I'm nitpicking.
            • swsieber 7y ago
              Thanks for the nitpick! I hadn't thought it through all the way. I was mostly thinking about doing async stuff with the inner stuff, but you're definitely right. I'm glad you commented because I've had to rethink it.
    • nixpulvis 7y ago
      True, but you can't chain returns, making this suggested use of a special postfix operation a bad idea imo.
      • Sharlin 7y ago
        You could chain returns in that case, in principle, but it would just be dead code. The type of a return expression is `!`, the never type.
  • kibwen 7y ago
    The post does mention that the hypothetical either-postfix-or-prefix-keyword idea would only apply to certain keywords, e.g. keywords that evaluated to non-useless values (which wouldn't include keywords like return, continue, fn, and so on).
• a1369209993 7y ago
  The problem with that is return doesn't evaluate to anything, so there's no (return foo).bar expressions to benefit from that change. Same problem with break, continue, and goto, for that matter.
• _nalply 7y ago
  I think yield would be a candidate for this syntax because yield can return.