-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
grammar: fix #33008
grammar: fix #33008
Conversation
Reading this, one item stood out a bit. Small improvements here. . ‘Compile-time’ is not a noun, ‘compilation time’ was meant; . Mathematical formulas are best not rendered as code; . Use the same tense as in other items.
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @brson (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
r? @steveklabnik not sure about the math conventions |
I am generally pro this PR, but we don't have any explicit convention regarding the math, and I think it would generally be displayed this way elsewhere. What's the specific objection here? |
Clarification by more precise specification.
I've submitted this PR for mainly just the typo in ‘equivalence’. The math style thing was something extra, should have been split off into a different commit. The big-O expression looks more conventional (i.e., MathJax style) when rendered in text font, even if sans serif, than when rendered in code font (i.e., monospace). The philosophy: it's better to do nothing (format math as text) than to do something that would be even more wrong (tag math as code). GitHub Flavored Markdown (GFM) does not support displaying math, it seems. Neither does GitHub render math when using e.g. the more complete markup language AsciiDoc. For big-O formulas, normal text formatting may suffice though. I've amended the PR, and I think it looks fine now. So, maximally exploiting GFM's standard text formatting functionality plus Unicode symbols could be taken as convention for math authoring for Rust. Alternatively, documentation could be partially migrated to Asciidoctor, as the OCaml team are doing recently. The value of that beyond math support would be a nicely formatted changelog at least outside GitHub (plus ToC, snippet inclusion, etc.). |
I'm on @sanmai-NL side. This look better like this. However, do we have an O notation somewhere else? |
We do use big O notation in a a few places, and I know at least every time I've written it, it's been in code. But, given that we have no strong convention, I will just merge this, and if we decide on an official convention we'll have to adjust them all anyway. @bors: r+ rollup |
📌 Commit 8ff34c7 has been approved by |
grammar: fix Reading this, one item stood out a bit. Small improvements here. 1. ‘Compile-time’ is not a noun, ‘compilation time’ was meant; 1. Mathematical formulas are best not rendered as code; 1. Use the same tense as in other items.
Reading this, one item stood out a bit. Small improvements here.