rustdoc-json-types: Inconsitant #[derive(
s
#96189
Labels
A-rustdoc-json
Area: Rustdoc JSON backend
T-rustdoc
Relevant to the rustdoc team, which will review and decide on the PR/issue.
#[derive(Clone, Debug, Serialize, Deserialize, PartialEq)]
: Most types#[derive(Clone, Debug, PartialEq, Eq, Hash, Serialize, Deserialize)]
:Id
#[derive(Clone, Debug, Serialize, Deserialize, PartialEq, Eq, Hash)]
:Header
andAbi
#[derive(Clone, Debug, Default, Serialize, Deserialize, PartialEq)]
:Generics
These are mostly a consequence of how they are used internaly (eg
Header
andAbi
haveHash
just because they used to be stored in aHashSet
,Generics
hasDefault
because we use it once inconversions
. We should aim to be more consistant and user facing in these traits.What Traits I thing we should have and why?
The super clear ones:
Serialize
andDeserialize
Clone
andDebug
are both super usefull, and I think everything should also Implement these, although it isn't required 1Id
needsHash
,Eq
andPartialEq
to be used as aHashMap
keyThe medium ones
PartialEq
for everything. It has clear semantics, and if we do rustdoc-json: replace jsondocck with jsondocckng #94140, it's essensialEq
for everything. If we doPartialEq
, we may as well do this,Hash
for almost everything. CurrentlyItem
andCrate
cannot do this because they haveHashMap
s. If we realy wanted to, we could replace these withBTreeMap
, but that would meanOrd
forId
and possible slower perf. Theirs alot of things that make sense to put in aHashMap
/HashSet
key, and I thing just not havingItem
andCrate
is fine. (I The fact thatType
didn't implementHash
was the reason I looked into this).Things to drop
Default
, as I don't think it's usefull or clear.cc @CraftSpider
@rustbot modify labels: +T-rustdoc +A-rustdoc-json
Footnotes
In practice, we depend on
Clone
forItem
, which means basicly everything else needs to beClone
, but I'm almost certain this can be removed ↩The text was updated successfully, but these errors were encountered: