Unify the style of combinator type descriptions #1501
Conversation
|
😁 I was thinking about doing exactly this soon after re-noticing the inconsistency in #1492. |
futures-util/src/future/empty.rs
Outdated
| /// A future which is never resolved. | ||
| /// | ||
| /// This future can be created with the [`empty()`] function. | ||
| /// Future for the [`empty`] combinator. |
There was a problem hiding this comment.
Are the free functions still "combinator"s? Maybe a better term here would be "constructor"?
There was a problem hiding this comment.
-- or drop "combinator"?
There was a problem hiding this comment.
Dropping "combinator" and rephrasing slightly to
Future produced by [`empty`].
seems ok to me.
There was a problem hiding this comment.
It may be easier to understand using "function"s and "method"s rather than "combinator"s (I do not think that functions like join_all is "constructor").
There was a problem hiding this comment.
That makes sense as well, so just replace "combinator" directly with "function" or "method" depending on which it is (or even go with just "function" everywhere since method is a sub-category of function).
There was a problem hiding this comment.
Checking the std docs they do differentiate between "function" or "method" for the iterator types, and don't mention "combinator" at all:
This
structis created by theoncefunction.
This
structis created by thefiltermethod onIterator.
taiki-e
force-pushed
the
docs-combinator-descriptions
branch
from
b15af51 to
7f3f471
Compare
|
Cool, thanks a lot for cleaning this up ❤️ |
Although I did not read each one in detail, I excluded those that might have explained in more detail than the functions/methods and those that would be unified if other PR(#1492) landed.
Closes #1214