Skip to content
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

Closed
jwosty opened this issue Jul 16, 2018 · 5 comments

Comments

@jwosty
Copy link
Contributor

jwosty commented Jul 16, 2018

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 ..."
  • and finally, 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).

@cartermp
Copy link
Contributor

100% agree, it should be unified on CEs.

@jwosty
Copy link
Contributor Author

jwosty commented Jul 16, 2018

I can certainly take this one within the next couple of days

@cartermp cartermp added this to the 16.0 milestone Jul 16, 2018
@chillitom
Copy link
Contributor

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 let! in an async builder might say "binds the result of an async computation" whilst let! in a maybe builder might say "binds the value of the option when Some otherwise causes the maybe computation expression to result in None". (Preferably with better wording).

Perhaps it could just pick up any doc comments from the associated builder methods if they exist.

@jwosty
Copy link
Contributor Author

jwosty commented Jul 18, 2018

@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?

@cartermp
Copy link
Contributor

This is now completed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants