utils icon indicating copy to clipboard operation
utils copied to clipboard

Where should `collectable` traits be implemented?

Open 8573 opened this issue 2 years ago • 3 comments

collectable suggests that its traits usefully could be implemented for heapless::Vec and tinyvec::Array, but collectable implements its traits only for the standard Vec<T>, and neither heapless nor tinyvec appear to implement collectable traits.

If I would like to use collectable with types other than Vec<T>, would it be appropriate to offer patches here, with the libraries providing the types (tinyvec, heapless, etc.) presumably becoming optional dependencies of collectable, or would you prefer that the implementations be in those libraries?

(cc @Lokathor)

8573 avatar Apr 02 '22 23:04 8573

I propose that if this crate wants to unify tinyvec and other crates that they depend on tinyvec and those other crates. Tintvec has been pleasantly stable for a while now, even min const generics didn't end up changing much, so it's not like it's gonna change out from under you any time soon.

Lokathor avatar Apr 03 '22 01:04 Lokathor

I'm glad there's some interest in collectable!

It was a prototype to replace aead::Buffer, which takes the approach suggested by @Lokathor and provides impls for various storage backends.

We never actually ended up trying to migrate to collectable instead, nor did we ever really find good applications for it outside the aead crate.

I still think it'd be nice to get fallible traits like collectable defines into core, though.

tarcieri avatar Apr 03 '22 14:04 tarcieri

nor did we ever really find good applications for it outside the aead crate.

My use-case was that I wanted to be generic over Vec<T>, tinyvec::ArrayVec<T>, smallvec::SmallVec<T>, etc., in a non-cryptographic library. Of course there are a number of crates intended to provide such traits (I even own a stub of one, which I'd forgotten), but collectable was the (IIRC) first I noticed while searching, and I figured that, as it's owned by an organization that I recognize and trust, it would have a lower chance of later becoming unmaintained or malicious; that its traits are fallible is an added advantage. I see now that it's neither used nor much developed. With traits such as these not in the standard library, would patches be welcome to add implementations of collectable's traits, or is this something that RustCrypto would prefer not to maintain?

8573 avatar Apr 03 '22 22:04 8573

@8573 sorry, just saw your question! (probably doesn't bode well impression-wise, heh)

Sure, we'd be happy if you'd like to contribute to it and help build it out. If it were a bit more mature we might actually use it.

It could always be made an optional dependency of aead with a blanket impl of aead::Buffer, which would allow aead::Buffer to work with more crates.

tarcieri avatar Oct 11 '22 23:10 tarcieri

@8573 sorry, just saw your question! (probably doesn't bode well impression-wise, heh)

Between @rust-secure-code, @RustSec, @RustCrypto, @iqlusioninc, I know you have many projects. 🤷

I no longer have an immediate use for these traits, but I imagine I will at some point. I imagine I'll implement such traits at some point, but not immediately. Anyway, my question is answered.

8573 avatar Oct 12 '22 08:10 8573