Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A final proposal for Rust await syntax

boats.gitlab.io

Post reply on HN
Print view View original

151–160 of 265 posts

Re: A final proposal for Rust await syntax

#151

Post by jnetterf »

hombre_fatal wrote: post #119
mklein994 wrote: post #48

The syntax feels a bit Ruby-ish, doesn't it? Here's an example from the article of how they could expand the syntax in the future: foo.bar(..).baz(..).match { Variant1 => { ... } Variant2(quux) => { ... } } Compared to some Ruby: 5.times { puts "Hello world!" } Note I'm by no means an expert in Ruby or Rust, this is just what I thought of when I saw the syntax.

A .match "method" just opens the dam to "why stop there?" I prefer Kotlin's general approach of .let and similar: number = foo.bar().baz().let { match it { A => 1 B => 2 } } Now anyone has the general tool for chaining without needing library authors or language designers to create the API for them.

Neat! When working with Options/Results/Iterators, you can use `.map` [1] for exactly this purpose. It would sometimes be convenient to have something like `.map` / `.let` on unwrapped values as well.

[1] https://doc.rust-lang.org/std/option/enum.Option.html#method..., https://doc.rust-lang.org/std/result/enum.Result.html#method..., https://doc.rust-lang.org/std/iter/trait.Iterator.html#metho...

Re: A final proposal for Rust await syntax

#152

Post by pablasso »

M2Ys4U wrote: post #110
jkarneges wrote: post #75

I figure the reason the proposed syntax looks gross is because other languages have been using a prefixed await for many years. The Rust decision seems well thought out though, enough to make me wonder if perhaps other languages have been doing it wrong. My first experience with futures was in the form of QFuture ( https://doc.qt.io/qt-5/qfuture.html ), and there you call .result() to block and wait for the result. T…

At first I was firmly in the prefix camp, until I read one of the (massive!) GitHub issues on the subject and came around to postfix. I'd _much_ rather use something like `?` than `.await`, though. Using a keyword just feels wrong in a few different ways.

Can you share said issue?

Re: A final proposal for Rust await syntax

#154

Post by Buttons840 »

andrewflnr wrote: post #142

I'm sold. This post did a good job of addressing my concerns with the syntax, plus a couple others. I'm now looking forward to postfix match. I still kind of want postfix macros, though. I saw a couple other neat use cases like `file.write!(...)`

User definable postfix macros might be nice, I don't know.

But we don't need user definable postfix macros to have a single `expression.await!()` as a magical macro. There are already magical macros, and to most Rust users `foo!()` means "magic here, read the docs". It would have been syntactically consistent to have `await!()` also mean "magic here, read the docs".

100% of Rust users will recognize the inconsistency of overloading field access syntax. Only a portion of Rust users will dig deep enough into macros to recognize that `expression.await!()` is special and is not defined as a normal macro. By the time a user digs deep enough to realize that, they are ready to understand why that inconsistency was necessary.

With `expression.await` new users may ask about the inconsistency and the answer will be "because reasons you can't understand right now".

Re: A final proposal for Rust await syntax

#155

Post by lucideer »

dj-wonk wrote: post #133
lucideer wrote: post #131

This is way way off-topic but: I have never seen the word "postfix" used in this way. "Suffix" is the normal/common English word for this as far as I've always been aware. A quick search has it listed it as a synonym, but I can't find any usage outside tech and it sure seems like a tech-industry/coding erroneous neologism trying to balance the seemingly logical "post" -vs- "pre". Am I way off the mark here?

Yes, "postfix" is commonly used. See http://www.cs.man.ac.uk/~pjj/cs212/fix.html or https://en.wikipedia.org/wiki/Reverse_Polish_notation

Reverse polish notation is an entirely different usage: not the same meaning as used in this proposal.

It's also commonly used as the name of a piece of email software, but that's also an unrelated usage to this.

Re: A final proposal for Rust await syntax

#156

Post by lucideer »

steveklabnik wrote: post #144
lucideer wrote: post #131

This is way way off-topic but: I have never seen the word "postfix" used in this way. "Suffix" is the normal/common English word for this as far as I've always been aware. A quick search has it listed it as a synonym, but I can't find any usage outside tech and it sure seems like a tech-industry/coding erroneous neologism trying to balance the seemingly logical "post" -vs- "pre". Am I way off the mark here?

Prefix/postfix Affix/suffix All of this stuff has different histories and slightly different usage, but yeah.

You seem to be presenting affix/suffix as opposites? Prefix & suffix are opposites: affix is the superset of both.

Re: A final proposal for Rust await syntax

#157

Post by steveklabnik »

erikpukinskis wrote: post #150
steveklabnik wrote: post #60

Earlier quoted context omitted.

If every choice was obvious, there would be no need for a designer in the first place.

Who said any choice was obvious? (Also would love your take on the question in the last line of my comment. My gut as an outsider is that the best solution may be cultural not technical, except Rust is struggling to implement cultural projects now that the community is scaling fast. But you know what I don't.)

Heres the most straightforward answer I can give: http://aturon.github.io/2018/04/24/async-borrowing/

Re: A final proposal for Rust await syntax

#158

Post by sinistersnare »

msla wrote: post #80
jmcomets wrote: post #5

Earlier quoted context omitted.

Disambiguation is easy when `await` is a keyword. [0] ;) error[E0721]: `await` is a keyword in the 2018 edition --> src/lib.rs:2:5 | 2 | await: i32 | ^^^^^ help: you can use a raw identifier to stay compatible: `r#await` [0] https://play.rust-lang.org/?version=stable&mode=debug&editio...

Programming languages didn't used to have reserved words: https://en.wikipedia.org/wiki/Reserved_word > Not all languages have the same numbers of reserved words. For example, Java (and other C derivatives) has a rather sparse complement of reserved words—approximately 50 – whereas COBOL has approximately 400. At the other end of the spectrum, pure Prolog and PL/I have none at all. I don't really know why modern prog…

I don't know about PL/I but Prolog kind of cheats, in my opinion, about the reserved words. It is very strict about naming conventions, which is (IMO) worse than having reserved words.

Re: A final proposal for Rust await syntax

#159

Post by steveklabnik »

lucideer wrote: post #156
steveklabnik wrote: post #144

Earlier quoted context omitted.

Prefix/postfix Affix/suffix All of this stuff has different histories and slightly different usage, but yeah.

You seem to be presenting affix/suffix as opposites? Prefix & suffix are opposites: affix is the superset of both.

Errr yes my bad.

Re: A final proposal for Rust await syntax

#160

Post by asdkhadsj »

mintplant wrote: post #145
nixpulvis wrote: post #141

Earlier quoted context omitted.

See, now this is exactly my issue with this syntax, I generally expect to be able to "chain" things with the "." notation.

You can chain .await, though. let n = future_of_future_of_int .await .await;

Curiously, will there be limitations to where it can be used? Eg, imagine a `foos.iter().map(|f| f.await).collect::>()`?

That seems crazy, think it'll be possible?

Post reply on HN