This would enable additional flexibility in the future (allow us to add trait methods with default impls).
As a type (in its current definition), it benefits from update syntax, which allows downstream implementations to reuse most of an existing implementation and replace a part of it.
However, even if we have a trait, we could also provide a "default" type that can still be used like that.
CryptoProvider was originally conceived as a trait but reworked to be a type in #1628. Reviewing the PR description, I think most of the advantages would still hold if we switched back to a trait (+ type).
IIRC around the QUIC changes for 0.23 (around #1798) there was some motivation to make changed to CryptoProvider (add more fields) in a way that the current design does not allow.
This would enable additional flexibility in the future (allow us to add trait methods with default impls).
As a type (in its current definition), it benefits from update syntax, which allows downstream implementations to reuse most of an existing implementation and replace a part of it.
However, even if we have a trait, we could also provide a "default" type that can still be used like that.
CryptoProviderwas originally conceived as a trait but reworked to be a type in #1628. Reviewing the PR description, I think most of the advantages would still hold if we switched back to a trait (+ type).IIRC around the QUIC changes for 0.23 (around #1798) there was some motivation to make changed to
CryptoProvider(add more fields) in a way that the current design does not allow.