6 ms·

My dislike for the ”dot keyword” syntax has been strong, but if it is selected, hopefully it’s at least generalized to other keywords in the future, so that `.a

My dislike for the ”dot keyword” syntax has been strong, but if it is selected, hopefully it’s at least generalized to other keywords in the future, so that `.await` doesn’t stay a lone awkward exception to what dot notation means. In particular, I wouldn’t mind if in the future `expr?` could be spelled `expr.try` for consistency (even at the expense of introducing redundancy).

saghm 8y ago
I like that idea for try! Near the bottom of the blog post, they mention that `match` could become a "dot keyword" expression, giving the following example: foo.bar(..).baz(..).match { Variant1 => { ... } Variant2(quux) => { ... } }
faitswulff 8y ago
The post says as much: > In particular, some members of the language team are excited about a potential future extensions in which some “expression-oriented” keywords (that is, those that evaluate to something other than ! or ()) can all be called in a “method-like” fashion. In this world, the dot await operation would be generalized so that await were a “normal” prefix keyword, but the dot combination applied to several such keywords, most importantly match:
- Sharlin 8y ago
  Yeah, that’s what I referred to, just wasn’t very clear.
gamegoblin 8y ago
I wonder if I would ever find something like my_iter .foo() .bar() .return more appealing than return my_iter .foo() .bar(); I could see it happening, but I'll definitely need some time to get used to it.
- nixpulvis 8y ago
  See, now this is exactly my issue with this syntax, I generally expect to be able to "chain" things with the "." notation.
  - mintplant 8y ago
    You can chain .await, though. let n = future_of_future_of_int .await .await;
    - asdkhadsj 8y 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 8y 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 8y 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 8y ago
deleted 8y ago
[deleted]

saghm 8y ago

I like that idea for try! Near the bottom of the blog post, they mention that `match` could become a "dot keyword" expression, giving the following example: foo.bar(..).baz(..).match { Variant1 => { ... } Variant2(quux) => { ... } }

faitswulff 8y ago

The post says as much: > In particular, some members of the language team are excited about a potential future extensions in which some “expression-oriented” keywords (that is, those that evaluate to something other than ! or ()) can all be called in a “method-like” fashion. In this world, the dot await operation would be generalized so that await were a “normal” prefix keyword, but the dot combination applied to several such keywords, most importantly match:

Sharlin 8y ago
Yeah, that’s what I referred to, just wasn’t very clear.

gamegoblin 8y ago

I wonder if I would ever find something like my_iter .foo() .bar() .return more appealing than return my_iter .foo() .bar(); I could see it happening, but I'll definitely need some time to get used to it.

nixpulvis 8y ago
See, now this is exactly my issue with this syntax, I generally expect to be able to "chain" things with the "." notation.
- mintplant 8y ago
  You can chain .await, though. let n = future_of_future_of_int .await .await;
  - asdkhadsj 8y 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 8y 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 8y 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 8y ago

deleted 8y ago

[deleted]