TheSignPainter98
commented
2 weeks ago This is a very good point, I completely agree. When writing this, I wasn't afraid of using lists as I was under the working assumption that this doc would function for both humans and for some tool to mechanically check many of these. This feels awkward though and leads to one or two situations where humans (the important readers) have to read stuff which isn't really written for them. It's definitely better to move more pedantic lists like this out of this doc to keep things people oriented.
For the list above, the existing (missing) rationale here goes as follows:
Copyshould come first as it drastically changes the ownership model of such a type and hence how its uses in code look (ownership is no longer moved, copies are made instead)Cloneshould come immediately afterCopyas they're strongly-associatedDebugshould come early as- The pairs
PartialEq+Eqare strongly-associated and so too arePartialOrd+Ord, but*Eqshould come first as it's typically more likely to be used. - Standard traits should come next followed by non-standard ones to avoid mixing standard and non-standard behaviours (which seems nice?)
This is quite complex though, perhaps something like the following could strike a better balance between human-friendliness and exhaustiveness:
Copy,CloneandDebugshould remain unchanged, due to the above rationale.- Strongly-associated traits should be grouped together
- Standard traits should come before third-party traits
Still haven't finished reviewed the whole document, but caught this in a reference from a PR:
Expecting people to remember what is standard or not is reasonable, and also somewhat implied by the fact they have to import them from somewhere. With that said, expecting people to keep the exact order for the first 7 items doesn't seem reasonable.
What is the underlying rationale here? If there is one, that's what we need to explain and people must keep in mind. Where there is none, it should be mechanical instead of memorized.