Open jvff opened 5 months ago
Mmm @afck suggested trait Witty: WitType + WitLoad + WitStore
. In general, trait aliases tend to denormalize the code (i.e. introduce degrees of freedom).
We can discuss the name of the trait. I think Witty
is too generic, and may cause confusion because it may seem it includes other traits present in the crate (like the WitInterface
trait that allows generating WIT interface snippets).
I'm not sure I understand the argument about denormalizing the code. I thought that we didn't introduce any more degrees of freedom because we constrained on both sides, with the trait dependencies on one (WitLoadStore: WitLoad + WitStore
and WitType
indirectly) and the blanket implementation on the other. So I think it's not possible to implement WitLoadStore
manually, because any attempt would clash with the blanket implementation.
re: degrees of freedom: Some developers will use the aliases and others won't.
Also, strictly speaking, these are not trait aliases.
I'm fine with the name WitLoadStore
, too!
If you prefer not to have the new trait, we could also add only the derive macro?
Motivation
It's very common to implement all three
WitType
,WitLoad
andWitStore
traits for types. Unfortunately, that leads to a verbose#[derive(WitType, WitLoad, WitStore)]
which, together with other derived traits can make the attribute occupy a lot of visual space.Proposed Solution
trait WitLoadStore : WitLoad + WitStore {}
trait alias inlinera-witty
beside the other traits.impl<T> WitLoadStore for T where T: WitLoad + WitStore {}
.WitLoadStore
trait inlinera-witty-macros
that generates theWitType
,WitLoad
andWitStore
trait implementations.