Because backtick tends to be a dead key.
I don't think so. It only needs to stand out among field access:
future
@await
.foo
.bar
@await
.baz
I agree.
1 Like
There are plenty of different ways to stand out. For example, here's an alternative formatting choice that I think also highlights the difference:
future.await
.foo
.bar.await
.baz
(Achieved by thinking about ? in the same situation, since I wouldn't put ? on its own line.)
1 Like
I'm not going to take it off my list, because it has its place, sorry. To improve your argument against it, though:
"it looks like an `i' at poor resolutions" (note nuance in typography)
¡Free 4K monitors for all Rust devs!
...or just when ¡ is shown out of context, as opposed to ¡await where I think most resolutions in common use can perceive the difference.
Anyway, if this is (via time travel?) the real sticking-point on alt-sigil, # is perfectly available as alternative and future extensible (by new RFC) sigil for: «postfix unary keyword/named operator». There is even the prior language precedent of Ruby, though it is used for something completely different. Many languages don't have such operators.
Rustfmt would scream in your face.
And it still looks like field access, so other people might feel the need to "make it right" by moving .await back to the line.
Only if it does not use a dot.
Also, I wouldn't put @ on its own line:
future@
.foo
.bar@
.baz
We can change rustfmt to allow and fix to this
8 Likes
So in addition to syntax highlighting, .await also needs a special formatting rule? I would say that exceptions like this are not a good sign. (even more if await will be a sole postfix keyword)
7 Likes
Why? It's a new type of construct, why shouldn't it have a new type of formatting rule?
5 Likes
What would you think of ::(await)?
I’ve made a crate to explore that: https://crates.io/crates/sonic_spin (await not included tho)
3 Likes
They were available. In fact it was the most heavily discussed thread in the history of Rust.
People who care about new Rust features need to follow the RFC repo, not rely on Reddit or IRLO.
The RFC repo is how decisions are made. If you wait for a post on Reddit / IRLO, you will be too late. There is a process. Learn how the process works.
8 Likes
Because it’s clearly an ad hoc solution to visibility issues, which do not exist for @await/#await/etc. .await reuses well established chaining conventions around dot and it will be very strange to introduce formatting exceptions here.
3 Likes
I like ::await better than .await
4 Likes
Considering turbo fish syntax (func::<T>) already exists, introducing another :: postfix wouldn't be inconsistent.
5 Likes
Firstly, I couldn’t have done this now, after having done the same then, on my spare time. I will just have to optimistically assume I’m getting involved at the right time, being a relatively newer user.
While I haven’t reviewed much of the RFC in retrospect, because of time and github being harder for this than IRLO, I have one initial retrospect comment:
Perhaps the (new) alt-sigil concept with an await keyword is a little undervalued now, because in the RFC then, it was mostly formulated as a single-character postfix sigil in the style of ?. So there was brief discussion of future@? for example, to mean await and then try. Well, I can easily imagine why that wasn’t well received, besides just the aesthetics. If your position is ASCII-only, this has room for how many postfix unary operators? Maybe 3? If post-ASCII, well, you are still thinking its going to turn into a mess very quickly:
future¡?☭
(Sorry, you just need to see that once!)
Unfortunately, that's just how life goes. There will always be new Rust users who are late to the discussions. There are plenty of discussions that happened years ago that I was late to. You just have to learn to accept that, and do your best to be a part of future discussions (by following the RFC repo).
The only way to fix the problem of people being late is to never make any decisions, just in case some new user wants to be part of the discussions. That obviously doesn't work.
Decisions need to be made. And the way that decisions are made is through the RFC repo. The official Rust website makes this very clear.
No, literally every possible syntax and variation on syntax was discussed. Every possible sigil was discussed. It was an incredibly massive thread. The #await and @await and @wait were brought up many many times (plus dozens of other sigils).
I really cannot emphasize this enough: every argument has been made. Every possibility has been discussed. Nothing has been overlooked. The decision was made based upon all of the available options.
The Rust team is incredibly thorough, and deeply cares about Rust, and the Rust community. They don't do a half-baked job.
27 Likes
So, the initial blog post mentioned that a final decision will be made on 23th, which was yesterday.
I have my sufficiently expanded upon my opinions, as have many others, and by now every argument has been made dozens of times.
I’m looking forward to the result.
Await will be great for the language, even if you disagree with the syntax choice. And seeing an end to the endless discussions about it and start enjoying the feature will hopefully be refreshing for everybody.
11 Likes
I was expecting an announcement yesterday.
3 Likes
The lang team needs time to write up their discussion, they’re not going to just drop a “this is the syntax” decision without the context of why they have chosen it. There should be a post soon once they have done so.
17 Likes
No proposal that requires developers to change their keyboard layout to write Rust will be a serious contender.
Please, step back for a moment, and seriously consider the experience for a new user, before proposing it yet again.
19 Likes
Agreed! I hereby concede the point. I believe I only seriously proposed it once. I’ve kept it on my personal list of alt. sigils, but I won’t be needing to share that any more. 