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

Update on await syntax in Rust

boats.gitlab.io

Post reply on HN
Print view View original

191–199 of 199 posts

Re: Update on await syntax in Rust

#191

Post by eximius »

eridius wrote: post #187
eximius wrote: post #186

Earlier quoted context omitted.

impl Future { fn await(self: Self) -> Self::Target { intrinsic::await(self) # compiler magic } } Then you CAN do `fut.await()` or `Future::await(fut)`, etc. Assuming this wouldn't be impossible for some other reason. And it makes it clear that `await` is magic, not something that a new programmer just can't find the definition of or assumes is the result of a macro or something. > we don't have these extra parens all…

It's impossible for some other reason. Namely, await isn't a matter of just inserting some compiler-defined behavior at a specific point. It requires rewriting the control flow of the surrounding function. The await! macro did this by invoking a magical unstable keyword `yield`, but even that still has to be done within the current function (e.g. the implementation of await! must be a macro, not a function).

I mean, that just means the compiler needs to ignore the `Future::await()` function scope and rewrite the context above. It's already being magical. A slight indirection in implementation would be worth the pedagogical clarity, I think.

Re: Update on await syntax in Rust

#192

Post by Retra »

anchpop wrote: post #20
Retra wrote: post #13

Earlier quoted context omitted.

What's a big difference for you got to do with the design of a language used by many others? What makes your experience more important than the experiences of someone with different qualifications? Why is optimizing for your tastes the correct thing to optimize for?

If it's a big difference to me, it would be surprising if it was not a big difference to some portion of people (in either direction, I wouldn't be surprised if most people hate it). Since it makes a big difference to some portion of people, it is worth discussing. My intention with my comment was to make the argument that spending a long time discussing syntax can be a useful and productive thing for language design…

If you're going to make that argument, you should probably be less vague. It makes a "big impact" to "some portion of people" that the Earth be thought flat, but you can't justify wasting a "long time" arguing about it.

Language designers don't need vague personal opinions masquerading as 'useful' facts, intentionally sculpted for inappropriate generalization. They need to know what the purpose of the syntax is and what the expectations of the language/user base are. Beyond that, you're just contributing noise.

And given that this criticism is largely against bikeshedding, it is interesting that you would try and justify it with statements of self-importance; bikeshedding largely happens because involving people in a decision leads them to massively over-value the importance of the decision simply because they are a part of it. You may be an expert on your own opinions, but if you're not an expert on their relevance, then you're not helping.

Re: Update on await syntax in Rust

#193

Post by chessturk »

jcelerier wrote: post #79
byproxy wrote: post #14

Earlier quoted context omitted.

Interesting example...I find the first much easier to read and reason about. ¯\_(ツ)_/¯

It would be nice for both of us to get a brain scan while reading that kind of code, because I find the second immensely more intuitive to parse

I find them completely equivocal. This is the geeky version of the orange/white dress.

Re: Update on await syntax in Rust

#194

Post by kbenson »

burntsushi wrote: post #190
kbenson wrote: post #143

Earlier quoted context omitted.

> It's like arguing traffic lights shouldn't use colors to indicate stop-and-go because some people either cannot perceive the color difference or choose to wear glasses that negate the color difference. There is a reason that we have three separate lights still instead of one (that is, there's more reasons than just inertia), and that's because some people can't tell the color differences. Specifically, my father ca…

> but consider it in context Which is exactly what has been done. So I don't understand what you're complaining about. The rest of your comment is a giant straw man. I've never heard of or seen implied that anyone in any decision making position in the Rust project is "assuming everyone has syntax highlighting set up." When you make ridiculous assumptions about the decision procedures of other people, then it's easy…

I never made an argument about the Rust project assuming that. I'm talking about people using the availability syntax highlighting to dismiss a negative aspect of a possible choice. I was making that argument in general, but spurred by a specific comment here. I used the context of the Rust community discussion as an example, but never did I assume Rust was using this as a metric (just noting that it has been put forth in arguments from the community).

My argument at this point (as illustrated by the Rust discussion) is simply:

- Rust/rustc takes in unicode text as source

- Since it has no knowledge at the source level of syntax highlighting, using that to mitigate the downside of a language level syntax for a feature is problematic

- We as the public should keep that in mind when discussing the relative merits of one possible implementation or another of a feature.

That's not denigrating or assuming Rust actually did this, it's a note about the community level discussion and how some people approached it, as evidenced by a very specific comment in this thread, and how I thought it had some problems when applied to language level decisions.

Re: Update on await syntax in Rust

#195

Post by burntsushi »

kbenson wrote: post #194
burntsushi wrote: post #190

Earlier quoted context omitted.

> but consider it in context Which is exactly what has been done. So I don't understand what you're complaining about. The rest of your comment is a giant straw man. I've never heard of or seen implied that anyone in any decision making position in the Rust project is "assuming everyone has syntax highlighting set up." When you make ridiculous assumptions about the decision procedures of other people, then it's easy…

I never made an argument about the Rust project assuming that. I'm talking about people using the availability syntax highlighting to dismiss a negative aspect of a possible choice. I was making that argument in general , but spurred by a specific comment here. I used the context of the Rust community discussion as an example, but never did I assume Rust was using this as a metric (just noting that it has been put fo…

All someone said was "Await is a keyword, syntax highlighters will most likely paint it differently." Which is a perfectly cromulent thing to say, and isn't contradictory of anything you're saying. Now if someone said, "it's impossible to read the await keyword due to its placement, but since everyone uses syntax highlighting, it will be okay since it will be colored differently," then you'd have a point.

I guess I'm just so tired of folks piping up with the "not everyone uses syntax highlighting" crap almost every single time anyone even hints at the notion that syntax highlighting can help a particular piece of syntax. I guess you're probably tired of the opposite.

Re: Update on await syntax in Rust

#196

Post by kbenson »

burntsushi wrote: post #195
kbenson wrote: post #194

Earlier quoted context omitted.

I never made an argument about the Rust project assuming that. I'm talking about people using the availability syntax highlighting to dismiss a negative aspect of a possible choice. I was making that argument in general , but spurred by a specific comment here. I used the context of the Rust community discussion as an example, but never did I assume Rust was using this as a metric (just noting that it has been put fo…

All someone said was "Await is a keyword, syntax highlighters will most likely paint it differently." Which is a perfectly cromulent thing to say, and isn't contradictory of anything you're saying. Now if someone said, "it's impossible to read the await keyword due to its placement, but since everyone uses syntax highlighting, it will be okay since it will be colored differently," then you'd have a point. I guess I'm…

> All someone said was "Await is a keyword, syntax highlighters will most likely paint it differently."

Which was in response to someone's criticism regarding .await notation that "it's easy to not even be aware it exists and think a struct had a member called await instead..."

> Now if someone said, "it's impossible to read the await keyword due to its placement, but since everyone uses syntax highlighting, it will be okay since it will be colored differently,"

That's how I interpreted it based on it being a reply to that exact criticism.

> I guess I'm just so tired of folks piping up with the "not everyone uses syntax highlighting" crap almost every single time anyone even hints at the notion that syntax highlighting can help a particular piece of syntax. I guess you're probably tired of the opposite.

I understand! As I noted earlier, I'm for syntax highlighting in general. If I was forced to never use syntax highlighting for programming again, I might consider a career change and only programming on things I really care about instead of to pay the bills. It's because of this extreme distaste for how annoying it is without syntax highlighting that I'm extremely adverse to making it any worse than it already is, because there's been a few times where I've been forced to endure it.

For the record, I'm fine with the currently accepted await syntax. Out of what I would consider the ideal outcome to me (postfixing special sigil/character), it's at least postfixed. While prefixing await looks prettier in the singular case, it makes any sort of chaining cumbersome and error prone to parse out by eye, and as I've gone to pains to represent here, when it comes to functionality and prettiness, I error heavily on the side of functionality (where functionality includes safety and a premium on not making complex things harder to deal with than they need to be). My comments are really a tangent on the submission topic and not meant to be applied directly towards the specific solution Rust has gone with (there's a reason I waited until quite deep in the thread to use it specifically as an example). That is, .await is a perfectly acceptable outcome in my eyes without the need to justify it through syntax highlighting.

Re: Update on await syntax in Rust

#197

Post by Too »

kibwen wrote: post #82
Nican wrote: post #71

Earlier quoted context omitted.

For example, on C#, I sometimes have to do: var value = (await (await startRequest()).GetBody()).Root; While the Rust syntax would make this a little more clear, I do not think it is a dealbreaker.

For ease of comparison, here's how that would look with syntax akin to Rust's choice: var value = startRequest().await.getBody().await.Root;

While we are doing comparisons, here is the Promise version:

    startRequest()
        .then(req => req.getBody())
        .then(body => { value = body.Root })

Re: Update on await syntax in Rust

#198

Post by a1369209993 »

steveklabnik wrote: post #167
a1369209993 wrote: post #166

Earlier quoted context omitted.

That seems to be what this proposal is already working toward, eg with the discussion of also supporting .match. keyword EXPR MAYBEBODY EXPR.keyword MAYBEBODY

From the post: > “Dot keyword:” In the previous post, a sketch was made of an idea in which certain keywords could be postfixed or infixed using the dot operator. This idea is only a sketch, and is not implied or guaranteed by the decision we’ve made here.

Ah, pity; I originally read it as "We aren't sure which - if any - keywords we want to do this to.".

Re: Update on await syntax in Rust

#199

Post by burntsushi »

kbenson wrote: post #196
burntsushi wrote: post #195

Earlier quoted context omitted.

All someone said was "Await is a keyword, syntax highlighters will most likely paint it differently." Which is a perfectly cromulent thing to say, and isn't contradictory of anything you're saying. Now if someone said, "it's impossible to read the await keyword due to its placement, but since everyone uses syntax highlighting, it will be okay since it will be colored differently," then you'd have a point. I guess I'm…

> All someone said was "Await is a keyword, syntax highlighters will most likely paint it differently." Which was in response to someone's criticism regarding .await notation that "it's easy to not even be aware it exists and think a struct had a member called await instead..." > Now if someone said, "it's impossible to read the await keyword due to its placement, but since everyone uses syntax highlighting, it will…

Aye, cheers. Understandable!
Post reply on HN