As an example of this, i remember a huge debate at the time about `await foo()` vs `foo().await` syntax. The community was really divided on that one, and there was a lot of drama because that's the kind of design decision you can't really walk back from.

Retrospectively, i think everyone is satisfied with the adopted syntax.

It makes sense that there was a huge debate, because the postfix .await keyword was both novel (no other languages had done it that way before) and arguably the right call. Of course, one can argue that the ? operator set a relevant precedent.

> Retrospectively, i think everyone is satisfied with the adopted syntax.

Maybe it’s a case of agree and commit, since it can’t really be walked back.

Various prominent people have said years after that .await was the correct choice after all

I'm not prominent but I disagreed with it at the time and I was wrong.

I’m curious - why were you wrong? It still seems like a wart to me, all these years later. What am I missing?

Contrast it with async in JS/ES as an example... now combine it with the using statement for disposeAsync instances.

    await using db = await sqlite.connect(await ctx.getConfig("DB_CONN"));
It's not so bad when you have one `await foo` vs `foo.await`, it's when you have several of them on a line in different scopes/contexts.

Another one I've seen a lot is...

    const v = await (await fetch(...)).json();
    
Though that could also be...

    const v = await fetch(...).then(r => r.json());
In any case, it still gets ugly very quickly.

I’ve never in my life used JS, so I’ll have to take your word for it.

It's a language I'm familiar with that uses the `await foo` syntax and often will see more than one in a line, per the examples given. C# is the most prominent language that has similar semantics that I know well, but is usually less of an issue there.

I'll give my two cents here. I work with Dart daily, and it also uses the `await future` syntax. I can cite a number of ergonomic issues:

```dart (await taskA()).doSomething() (await taskB()) + 1 (await taskC()) as int ```

vs.

```rust taskA().await.doSomething() taskB().await + 1 taskC().await as i32 ```

It gets worse if you try to compose:

```dart (await taskA( (await taskB( (await taskC()) as int )) + 1) ).doSomething() ```

This often leads to trading the await syntax for `then`:

```dart await taskC() .then((r) => r as i32) .then(taskB) .then((r) => r + 1) .then(taskA) .then((r) => r.doSomething()) ```

But this is effectively trading the await structured syntax for a callback one. In Rust, we can write it as this:

```rust taskA(taskB(taskC().await as i32).await + 1).await.doSomething() ```

Two spaces before a line make it a code block literal

  This is a code block
HN has never used markdown so the triple-tick does nothing but create noise here.

Thnaks for heads up, I'll keep this in mind in the future.

I was a proponent of the postfix macro solution. `.await!` or `.await!()`, essentially. The idea was that this could be generalized, it was closer to existing syntax, etc.

I was worried about features that I still don't love like `.match` etc (I'm more open to these now).

Post-fix macros would have been very complex. Scoping alone is complex.

`.await` kinda just works. It does everything you want and the one cost is that it looks like a property access but it isn't. A trivial cost in retrospect that I was a huge baby about, and I'll always feel bad about that.

The postfix macro does sound like a better solution tbh. Did you write the static assertions crate? If so, thank you. I’m a daily user.

Ha, no, I did not write that crate. I think my use of this username probably predates rust, certainly that crate.

Postfix macros had some very tricky issues and it would have delayed things a lot to figure out the right resolution.

I was initially very against postfix await and I was wrong. It's great.