-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Further changes #6
Further changes #6
Conversation
Renamed |
Don't merge yet, I want to add a commit that changes |
|
Don't merge yet. I have concerns that we'll be happy with our choice if we choose the name |
As an experiment I've renamed |
144f448
to
2b16621
Compare
My naming effort didn't catch on 😅 Here's the updated PR which renames everything from |
26f72d9
to
508dc63
Compare
508dc63
to
95d0c9a
Compare
@aturon @withoutboats Any update on this? |
8c98a17
to
3bbe790
Compare
ac01c4f
to
6a09fdb
Compare
6a09fdb
to
ea55d5d
Compare
eb60598
to
46e58ae
Compare
d84fb67
to
d890d61
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In addition to the few specific comments, I think the introduction of code blocks here is a stylistic downgrade that makes the RFC less readable. Backticks should be used for keywords when discussing the keyword and for traits when discussing the type, not any time they are used. Several prominent examples:
- An async function is annotated with the
async
keyword, but that does not mean it should always be written "async
function." - A
return
expression must evaluate to the return type of the function, but that does not mean that type should be referred to as the "return
type". - A future is a type that implements
Future
, but that does not mean that you must always call them "Future
s". - You can "await" a future using the
await!
keyword, but that doesn't mean you must always "await
a future" (indeed, in this case, in this RFC, any time await should be backticked it should be writtenawait!
, since it is a built-in macro and not normal syntax.)
Backticks should only be used when they improve understanding by clarifying that we are referring to a particular piece of code, not to the concept that that code would also refer to.
I'm going to merge the RFC now, but feel free to make another PR against the RFCs repo and request my review to make any of the other amendments this PR contains.
anonymous type which implements `Future`. As that future is polled, the | ||
function is evaluated up to the next `await` or return point inside of it (see | ||
the await syntax section next). | ||
`async` functions work differently than normal functions. When an `async` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"different from" is correct: https://www.grammar.com/different-from-vs-different-than
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting. Didn't know that. (I'm from Germany ;)
reverse course after stabilizing these features, it will be quite costly. | ||
Adding an alternative mechanism for asynchronous programming would be more | ||
costly because this exists. However, given our experience with futures, we are | ||
costly because this exists. However, given our experience with s, we are |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
replaced "futures" with "s"
Yes I wasn't so sure about whether styling all these words as code is a good idea myself. I'll create create a PR that only contains the other tweaks. |
Future
->Async
Rendered