5 ms·

It's sugar for existing features. "await"ing existed before but required some really messy syntax to achieve the same thing. It's very much an incredible improv

It's sugar for existing features. "await"ing existed before but required some really messy syntax to achieve the same thing. It's very much an incredible improvement over the status quo.

eximius 7y ago
I'm aware. I just believe that the design decision around `future.await` was dumb. Preface: this is a minor syntactical annoyance that aesthetically and in principle annoys me a great deal, but in practice is unlikely to cause much confusion. The rest of this should be considered a light hearted rant. `future.await` looks like it should be field access, not running arbitrary code for a future. It should have either been a keyword (a la `await future`), or some language built in trait method (like `future.await()`), of which there is precedent for things that require compiler magic. The arguments against macro or method like syntax were "but it's not a function in the mathematical sense", which is ironic given they chose something that looks like field access, and irrelevant in that I could have a function call inline assembly and just jump elsewhere, ignoring their concept of mathematical functions and stacks anyway. I'll admit that the post-`future` syntaxes have the benefit of chaining, which is why I prefer `future.await()` over `await future` or `await!(future)`, but I still stand by that `future.await` was the wrong choice. So my main problem is that they made a poor design choice from what seemed an obvious pool of candidates (to me). The worry is that it'll happen again for more bizarre features that happen to be lobbied for. /Endrant
- tele_ski 7y ago
  I'm also in this camp, I did read through at the time some of the arguments for this syntax and it allows for some elegant chaining of awaits and other things I can't recall, but I still can't get over the fact that it looks like a member access and also for such an important meaning to the current line of code it isn't boldface right at the start screaming "im async". Nope it's at the end of the line and doesn't standout in any meaningful way since it's a member access. I find it very unfortunate
- zozbot234 7y ago
  `.await` is just a postfix keyword. You seem to be concerned that it reuses the `.` sigil, but there are only a few distinct sigils available in the ASCII character set so having some reuse is quite inevitable even in principle.
  - eximius 7y ago
    Yes, there are few sigils and they were reluctant to add more (like ooollld Rust). However, Ive made my case as to which option I think was better and less ambiguous. We'll just have to disagree that this was inevitable.

It's sugar for existing features. "await"ing existed before but required some really messy syntax to achieve the same thing. It's very much an incredible improvement over the status quo.

eximius 7y ago

I'm aware. I just believe that the design decision around `future.await` was dumb. Preface: this is a minor syntactical annoyance that aesthetically and in principle annoys me a great deal, but in practice is unlikely to cause much confusion. The rest of this should be considered a light hearted rant. `future.await` looks like it should be field access, not running arbitrary code for a future. It should have either been a keyword (a la `await future`), or some language built in trait method (like `future.await()`), of which there is precedent for things that require compiler magic. The arguments against macro or method like syntax were "but it's not a function in the mathematical sense", which is ironic given they chose something that looks like field access, and irrelevant in that I could have a function call inline assembly and just jump elsewhere, ignoring their concept of mathematical functions and stacks anyway. I'll admit that the post-`future` syntaxes have the benefit of chaining, which is why I prefer `future.await()` over `await future` or `await!(future)`, but I still stand by that `future.await` was the wrong choice. So my main problem is that they made a poor design choice from what seemed an obvious pool of candidates (to me). The worry is that it'll happen again for more bizarre features that happen to be lobbied for. /Endrant

tele_ski 7y ago
I'm also in this camp, I did read through at the time some of the arguments for this syntax and it allows for some elegant chaining of awaits and other things I can't recall, but I still can't get over the fact that it looks like a member access and also for such an important meaning to the current line of code it isn't boldface right at the start screaming "im async". Nope it's at the end of the line and doesn't standout in any meaningful way since it's a member access. I find it very unfortunate
zozbot234 7y ago
`.await` is just a postfix keyword. You seem to be concerned that it reuses the `.` sigil, but there are only a few distinct sigils available in the ASCII character set so having some reuse is quite inevitable even in principle.
- eximius 7y ago
  Yes, there are few sigils and they were reluctant to add more (like ooollld Rust). However, Ive made my case as to which option I think was better and less ambiguous. We'll just have to disagree that this was inevitable.