-
Notifications
You must be signed in to change notification settings - Fork 2
Unsized Cids #5
Comments
This looks like a an elegant way to have compile-time sizes and to erase that info when we don't want it. It looks like we can even do: #[derive(Debug, Clone, PartialEq, Eq, PartialOrd, Ord, Hash)]
#[doc(hidden)]
pub struct MultihashBase<T: ?Sized> {
code: u64,
size: u8,
digest: T,
}
#[derive(Debug, Clone, PartialEq, Eq, PartialOrd, Ord, Hash)]
#[doc(hidden)]
pub struct CidBase<T: ?Sized> {
version: Version,
codec: Codec,
hash: MultihashBase<T>,
}
impl<const S: usize> Copy for MultihashBase<[u8; S]> {}
impl<const S: usize> Copy for CidBase<[u8; S]> {} And get I wonder if as part of this we can also get rid of the So yes, definitely open to PRs on this! |
It's redundant when unsized, but I think we still need it when sized. Otherwise, it's difficult to construct variable-sized multihashes/cids.
But that would be a massively breaking change. Thoughts?
I'm not a fan of any of the options, but I'm leaning towards OT:
Test output:
|
Could you give me an example of a variable-sized multihash/cid where the size is actually used? Trying to see in what edge-cases where the digest length and the size would be different.
You need to do
No, I just assumed the derive wouldn't work. Tried it now and it does though, which is nice.
I like DynCyn/DynMultihash, but I think
is worth a second look, since
Seems like it might have some uses in some contexts.
|
Oh, just realized what you meant by "variable-sized multihash", you mean like a variable-digest hash where the digest size isn't divisible by 8, right? E.g. a 100 bit Blake3 won't be distinguishable from a 104 bit Blake3 without the |
I'm specifically thinking of cases where one might want to support different hash functions with different digests. At the moment, one would likely pick a reasonable maximum (e.g., what the standard Cid type does). This overestimation means the actual digest size needs to be stored.
Well... the way multihash works, any hash digest can be truncated.
Ah, got it. It should be fixable by adding a bunch of cfgs to the relevant tests.
Ah, I was in the multiformats repo. I'll copy it there. |
It completes the picture, but given that multihashes generally aren't built piecewise, I can't think of one except maybe as some kind of reusable cid scratch pad? I think |
Oh, you want to test all features. Yeah.. that makes sense and I have no idea how to fix that. |
So, I looked into |
Multihash implementation in https://github.com/Stebalien/sp-multihash/tree/feat/unsized. But we should resolve argumentcomputer/sp-multihash#7 first. |
I'm currently trying to define an "object safe" blockstore but I'd also like the blockstore to be generic over CID sizes. Unfortunately, I can't have generic functions in an object safe type.
However:
So I'd like to erase it. Luckily. This seems to be entirely possible in safe and stable rust using unsized types:
It may be possible to do this without redefining these types, but it likely requires liberal use of transmute and a custom deref function. The above implementation is probably faster and safer (and more likely to play well with the borrow checker, especially NLL.
Would you be open to a set of PRs to implement this?
The text was updated successfully, but these errors were encountered: