-
-
Notifications
You must be signed in to change notification settings - Fork 5.7k
RFC: [doc] drop colon in See also text #40401
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
Conversation
|
To make the counter-argument: Some are complete sentences to read, while others are just a list which you should not try to pronounce. If the second are consistently marked with a colon then perhaps that's useful hint not to hope for a grammatical sentence. Or, if the colons are removed, then perhaps many lists should have an "and" before the last? |
|
A colon should not change whether content can be read, or whether a list has an 'and' (perhaps just me, but I mentally add an 'etc' to any list that doesn't have an and/or to make it grammatical) |
|
@StefanKarpinski Since you're the main dissenting voice, in your opinion, do you suggest that we (a) keep the status quo (b) convert mostly in the other direction or (c) other? |
| convenience since decimal literals are converted to `Float64` when parsed, so | ||
| `BigFloat(2.1)` may not yield what you expect. | ||
| See also: |
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.
Just want to clarify: is the proposed style to use the colon at the start of a multi-line list, but not otherwise?
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.
Yes, in this case, it felt more grammatical with the colon because it is a multiline list.
We generally seem to prefer sentences over keyword lists (which feel a bit too much like Javadoc to me), so this changes the documentation to use a more free-form sentence for "see also," including an ending period (we seem to have intuitively preferred this already, by a ratio of 5:2).
We generally seem to prefer sentences over keyword lists (which feel a bit too much like Javadoc to me), so this changes the documentation to use a more free-form sentence for "see also," including an ending period (we seem to have intuitively preferred this already, by a ratio of 5:2).
We generally seem to prefer sentences over keyword lists (which feel a bit too much like Javadoc to me), so this changes the documentation to use a more free-form sentence for "see also," including an ending period (we seem to have intuitively preferred this already, by a ratio of 5:2).
We generally seem to prefer sentences over keyword lists (which feel a bit too much like Javadoc to me), so this changes the documentation to use a more free-form sentence for "see also," including an ending period. Vote now? 👍 👎
We seem to intuitively have preferred this already, by a ratio of 5:2: