-
Notifications
You must be signed in to change notification settings - Fork 789
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
Keyword descriptions of let-bang and friends should be consistent and not specifically refer to asyncs #5343
Comments
100% agree, it should be unified on CEs. |
I can certainly take this one within the next couple of days |
It would be really cool if there was a way to document computation expression builder methods so that intellisense and compiler warnings would adapt for the context of the builder. For example Perhaps it could just pick up any doc comments from the associated builder methods if they exist. |
@chillitom now that's a thought that's worth exploring. I wonder if that's possible -- it would depend on what phase of the compiler in which the keyword descriptions are read. The helper function that does that is keywordsWithDescription, and it's used by a few other things, so maybe it should be able to get this information dynamically from user code. Assuming this is possible, should it just take the comment from the associated builder method if it exists and use that as the description? |
This is now completed. |
As discussed in #4427 (review)
Some computation-expression keyword descriptions are inconsistent with each other in how they are described, and this should be fixed. For example:
let!
says it's "Used in asynchronous workflows ..."use!
says it's "Used ... in asynchronous workflows and computation expressions ..."return!
says it's "Used to indicate a computation expression ..."yield!
says it's "Used in a computation expression ..."match!
says it's "Used in computation expressions ..."All of these descriptions should be unified to either all say "Used in computation expressions", or "Used in a computation expression" (doesn't really matter which; just as long as they're consistent).
The text was updated successfully, but these errors were encountered: