Conversation
| /// according to the requirements of the variable's type. For example, a variable of | ||
| /// reference type must be aligned and non-null. This is an invariant that must | ||
| /// Every variable must be properly initialized according to the requirements of its type. | ||
| /// For example, a variable of reference type must be aligned and non-null. This is an invariant that must |
There was a problem hiding this comment.
You're still dong changes here without explaining the rhyme or reason for them. What is wrong with the sentence that you changed here, the first sentence of this section?
Sorry, I'm already swamped with reviews, I really don't have the time to tease out the meaningful changes from the gratuitous rewordings in a PR like this.
There was a problem hiding this comment.
The idea here is to remove the distraction of mentioning the compiler. (Since it is really the language definition that matters, not what the compiler assumes...)
There was a problem hiding this comment.
That is the rigorous way of talking about it, but not the most accessible way. We have to be careful not to turn the docs into unreadable (to most of the audience) legalese.
There was a problem hiding this comment.
In what way did my change make the text less accessible here? My change simplifies the text, while also making it more correct.
There was a problem hiding this comment.
I do not remember any more what exactly I was referring to. It wasn't just this change but the entire PR.
I will note though that even your new text above says "the compiler relies", so you are not being consistent about avoiding mentioning the compiler. We also do mention the compiler quite a bit elsewhere in the docs -- it's a framing programmers understand well. I don't think it is productive to bikeshed such stylistic choices, and it is not a good use of reviewer time to arbitrarily change a small subset of the docs from one style to the other.
I can help ensure the accuracy of new factual content being added, and I can help with changes that solve a clearly stated, concrete, local problem with the existing docs. I do not have the capacity to review purely editorial changes based on largely subjective preferences. Therefore, I will see myself out of this PR.
|
r? libs-api |
|
Please decide how yo want to continue with this: close one of #136689 or this PR, and then for the remaining PR, if you want me to review it I'd like you to explain every single change on a paragraph-by-paragraph basis. If that feels like too much, you're doing too many changes in one PR, so please cut it down -- there can always be a next PR. Smaller PRs are a lot easier to review. |
|
☔ The latest upstream changes (presumably #138714) made this pull request unmergeable. Please resolve the merge conflicts. |
|
@hkBst any updates on this? thanks |
124cd85 to
6079eee
Compare
|
This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
6079eee to
1382376
Compare
This is an attempt at excluding less impactful changes from #136689.
r? @RalfJung