You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A backend wrapper could be created that is parameterized by an allow-list which statically prevents things from being sent/received that shouldn't be.
First, this setup would let you define a new marker type and enumerate a specific set of types which are allowed on the "allow list" denoted by that type.
/// A marker type standing in for allowing every type to be serialized/deserialized.pubstructAllowAll;/// A marker trait that indicates whether or not the type `T` belongs to the allow-list `Self`.pubtraitAllow<T>{}/// The `AllowAll` marker type allows all types.impl<T>Allow<T>forAllowAll{}
Then, we would implement all the backend traits, forwarding their implementations, for Restricted, except adding the clause where List: Allow<T> to each impl.
A backend wrapper could be created that is parameterized by an allow-list which statically prevents things from being sent/received that shouldn't be.
First, this setup would let you define a new marker type and enumerate a specific set of types which are allowed on the "allow list" denoted by that type.
You would use it like so:
Because of trait coherence rules, nobody outside the crate in which
OnlyByteAndBool
can add another impl forOnlyByteAndBool: Allow<T>
for some newT
.Then, this abstraction can be used to implement a general restriction mechanism for backends:
Then, we would implement all the backend traits, forwarding their implementations, for
Restricted
, except adding the clausewhere List: Allow<T>
to each impl.Edited from the comment posted by @kwf in #107 (comment)
The text was updated successfully, but these errors were encountered: