-
Notifications
You must be signed in to change notification settings - Fork 121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(x509): add PkiPath type #466
Conversation
952ba35
to
36449d1
Compare
Signed-off-by: Nathaniel McCallum <nathaniel@profian.com>
/// | ||
/// [RFC 6066]: https://datatracker.ietf.org/doc/html/rfc6066#section-10.1 | ||
#[derive(Clone, Debug, PartialEq, Eq, Default, Newtype)] | ||
pub struct PkiPath<'a>(Vec<Certificate<'a>>); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like this could use some sort of accessor for the inner Certificate
s, such as AsRef<[Certificate<'a>]>
and/or something that exposes an Iterator<Item=&Certificate<'a>>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tarcieri Like #[derive(Newtype)]
? :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh right, I forgot it was adding Deref
/DerefMut
impls.
Thinking about that again, doing that unilaterally somewhat defeats the point of having a newtype, since it effectively leaks the inner type and precludes adding your own inherent methods (at least if you want it to be an idiomatic use of Deref
).
But that's something we can circle back on another day, I suppose.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The intent of newtype
is to expose the inner type, but allow the outer type to pick up implementations of traits relevant to specific contexts. Of note here is this new type: #479
This is particularly useful where an identical inner type is used in multiple contexts. A primary example of this is Vec<Extension>
which has different OIDs in different contexts. The outer type determines which Identifiable
instance to give to the inner type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The intent of newtype is to expose the inner type
This description is antithetical to the typical notion of "newtype", which is to encapsulate the inner type
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tarcieri I don't think the invariants of "newtype" are that well defined. They are commonly used to allow the implementation of a trait from one crate on the type from a second crate within a third crate, which is roughly how we're using them here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implicit deref coercion has somewhat magical and often surprising powers which allow you to transparently treat one type as another, which go well beyond what's typically meant by "newtype". It means you can't encapsulate the inner type, and it's a mandatory part of the public API.
A very common usage of the newtype pattern is to encapsulate another type to keep it out of the public API, so you can upgrade the dependency that provides the inner type without it resulting in a breaking change to the public API of the consumer providing the outer newtype.
No description provided.