A final proposal for Rust await syntax • Hacker News Board

Re: A final proposal for Rust await syntax

#241

Post by OtterCoder » Tue, May 07, 2019, 7:48 AM UTC

arcticbull wrote: post #124

After reviewing the syntax writeup, I've reached my own decision on what color the bikeshed should be. I like the "Unusual other syntaxes: Use a more unusual syntax which no other construction in Rust uses, such future!await." [1] (or future@await). It makes sense because it is in fact something different than what exists anywhere else in Rust so it should receive a commensurate syntactic treatment. This was written…

I'd tend to agree with you, except for the fact that Rust reserved words are reserved everywhere. Even if the syntax were changed, you still couldn't name a field "async" or "return". Since it's no extra burden on the namespace, I'm less opposed to it.

I'm on the fence about disambiguation via unique punctuation, vs avoiding Perl-like line noise.

Re: A final proposal for Rust await syntax

#242

Post by int_19h » Tue, May 07, 2019, 8:44 AM UTC

slezyr wrote: post #92

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…

> 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. Lua[1], C++/Boost[2] also use "yield" it's not that uncommon and there is nothing new. [1] https://www.lua.org/pil/9.1.html [2] https://www.boost.org/doc/libs/1_54…

It's not the question of keyword chosen, but rather where it should go.

I wrote a lot of async/await code in C#, where it's a prefix operator, and I think what they did makes more sense. C# syntax works great when all you're doing is awaiting on a single call per line, but as soon as you start doing e.g. method chaining, you have to put parentheses everywhere, and it gets real messy real fast. This looks cleaner.

Re: A final proposal for Rust await syntax

#243

Post by int_19h » Tue, May 07, 2019, 8:48 AM UTC

yxhuvud wrote: post #139

pcwalton wrote: post #118

Earlier quoted context omitted.

> Why does a parametrized enumerant look like a function call and not a struct? Because tuples are considered good things to have in a modern language. Structs and enum variants are just named versions of tuples (denoted with parentheses) or records (denoted with braces—unnamed records don't exist in Rust). To follow languages like Python, they're written "(1, 2, 3)". (It would be weird if tuples were written "{1, 2,…

> (It would be weird if tuples were written "{1, 2, 3}", right?) That is the case in Crystal. Doesn't feel weird - if anything it is consistent in that ()s always denote something to do with execution. Both ()s and {}s have multiple different other syntactic usages though, so it is not as if either is optimal.

Most languages that offer tuples, either use (), or just treat commas as "tuple operator" anywhere they don't have another meaning already. And this goes a long time back.

Function calls can then be treated as functions from a single tuple argument, as is idiomatic in SML.

Re: A final proposal for Rust await syntax

#244

Post by int_19h » Tue, May 07, 2019, 8:53 AM UTC

cyphar wrote: post #54

blattimwind wrote: post #41

Earlier quoted context omitted.

Wouldn't "await expr" or "await@expr" (if you hate whitespace) make more sense compared to "expr await"? let db_conn = await pool.connect() (Which is what e.g. Python uses, with the downside that you tend to need to parenthize more because await has very low precedence). vs let db_conn = pool.connect() await .await is not soo bad, kinda method-y let db_conn = pool.connect().await

I don't think "expr await" would be a good choice but that isn't the decision that was made, and I wasn't arguing for it in the first place. TFA says that using alternative punctuation was decided against because it would lead to line-noise and I don't think there's much more to discuss -- I understand that position and respect it. My main issue with .await is that it does look method-y rather than keyword-y. But whi…

Python also chains methods. And having to write (await (await (await foo).bar()).baz()) is annoying.

Re: A final proposal for Rust await syntax

#245

Post by int_19h » Tue, May 07, 2019, 8:58 AM UTC

msla wrote: post #170

sinistersnare wrote: post #158

Earlier quoted context omitted.

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.

PL/I is syntactically like Algol, or Pascal, or C with more words and fewer brackets. At heart, it's a "normal" block-structured procedural programming language, which proves that a C clone could adopt the same basic idea.

XQuery is probably a more recent example of that. No reserved words there, just syntax.

https://www.w3.org/TR/xquery-30/#nt-bnf

Re: A final proposal for Rust await syntax

#246

Post by int_19h » Tue, May 07, 2019, 9:11 AM UTC

lachlan-sneff wrote: post #44

I'm curious as to why the mandatory prefix syntax wasn't chosen (`await {...}`). It's less magic than a magic field and it fits into preexisting syntax better.

Try writing a chain of async member accesses and calls with . and ? like that.

Re: A final proposal for Rust await syntax

#247

Post by Sharlin » Tue, May 07, 2019, 9:45 AM UTC

a1369209993 wrote: post #224

Sharlin wrote: post #127

Earlier quoted context omitted.

Postfix in itself is fine, although "await" as a verb reads best in a prefix position (cf. "try", "match", "yield", "loop", "return"). The reason the "dot await" notation looks gross is first and foremost because it coopts the field access syntax—familiar from almost every language in the C family—for a purpose entirely orthogonal to field access.

> it coopts the field access syntax [...] for a purpose entirely orthogonal to field access You mean like C++'s a.this_method_is_a_function_call(...) did? Not to be confused with a.function_pointer_field(...), despite having literally identical syntax. Personally, I think they should have intoduced a dot-keyword instead of postfix ?; it's too easy to miss, especially for something that hides a implicit return.

Meh, method calling is a fairly straightforward extension to field access, not something entirely different. Incidentally, in Rust you do have to disambiguate between calling a method and invoking a function through a function pointer field.

Re: A final proposal for Rust await syntax

#248

Post by imtringued » Tue, May 07, 2019, 10:22 AM UTC

int_19h wrote: post #244

cyphar wrote: post #54

Earlier quoted context omitted.

I don't think "expr await" would be a good choice but that isn't the decision that was made, and I wasn't arguing for it in the first place. TFA says that using alternative punctuation was decided against because it would lead to line-noise and I don't think there's much more to discuss -- I understand that position and respect it. My main issue with .await is that it does look method-y rather than keyword-y. But whi…

Python also chains methods. And having to write (await (await (await foo).bar()).baz()) is annoying.

That doesn't look like well written async code at all... You're not supposed to use await literally everywhere and especially not multiple times in a single line.

Javascript already has an answer to this (Hint it was inspired by Monads but it isn't one):

await foo.then(f => f.bar()).then(b => b.baz())

Re: A final proposal for Rust await syntax

#249

Post by mruts » Tue, May 07, 2019, 11:17 AM UTC

Why doesn’t Rust just implement HKT and then make a Future a monad. It seems to me that Rust has too many special things that arise from a lack of expressiveness as it is.

HKT would make things considerably nicer.

Re: A final proposal for Rust await syntax

#250

Post by steveklabnik » Tue, May 07, 2019, 11:32 AM UTC

mruts wrote: post #249

Why doesn’t Rust just implement HKT and then make a Future a monad. It seems to me that Rust has too many special things that arise from a lack of expressiveness as it is. HKT would make things considerably nicer.

https://twitter.com/withoutboats/status/1027702531361857536