der: why don't more ASN.1 types support conversion to `Any(Ref)`?

[RickyDaMa]

Hi there! I'm new to the RustCrypto libraries, so if I'm holding them wrong and there's a smooth way to go from one to the other, please point it out 😅

I'm trying to build an x509_cert::attr::Attribute by hand using constants. What I'd like to do is something like this:

let attr = Attribute {
    oid: SPC_LINK,
    values: SetOfVec::from_iter(
        [BitString::from_bytes(&[0x00]).unwrap().into()] // .into() here converts BitString to Any
    ).unwrap(),
};

Is there a reason why we don't have implementations such as From<BitStringRef<'a>> for AnyRef<'a>? If it's just a case of "no one has needed it yet", would you accept a PR for such things?

And on a similar note, could the derive macros also potentially implement Any conversion also? I guess you might struggle to distinguish between owned and borrowed structs to know which to implement (or how)

[RickyDaMa]

I think I've just found the intended way of doing this: using Any::encode_from. I guess this is a separate method because it allowed specialised impls of From/TryFrom with AnyRef?

[dishmaker]

I think explicit conversion should be preferred here,
just like you can't do:

let path: Path = OsStr::new("foo.txt").into()

but you can explicitly create Path::new:

Path::new(OsStr::new("foo.txt"))

which is a little verbose.

[tarcieri]

@RickyDaMa the BitStringRef type currently stores the unused bits field separately from the rest of its backing slice:

https://github.com/RustCrypto/formats/blob/858f3af9/der/src/asn1/bit_string.rs#L23

This makes it possible to e.g. have constructors which don't require it to be stored contiguously with the rest of the slice:

https://github.com/RustCrypto/formats/blob/master/der/src/asn1/bit_string.rs#L40

However, AnyRef has a requirement that the entire value is stored in a contiguous slice.

Since Any allocates, it can allocate and serialize to a backing buffer it controls on the heap, so it doesn't have such a problem.

[RickyDaMa]

I think explicit conversion should be preferred here,

Then why do some asn1 types allow the 'implicit' conversion? I wouldn't mind if everything was explicit, my confusion arose because of the mix of approaches

AnyRef has a requirement that the entire value is stored in a contiguous slice.

Since Any allocates, it can allocate and serialize to a backing buffer it controls on the heap, so it doesn't have such a problem.

Okay so you couldn't implement From<BitString> for AnyRef, but you could implement From<BitString> for Any, right? Is there any reason not to do that (I guess that also could feel a bit inconsistent)?

[dishmaker]

We can't implement From<BitString> for AnyRef,
because it would need to allocate N+1 bytes for the unused_bits: u8.

[dishmaker]

If BitStringRef didn't have unused_bits: u8 and just &'a [u8] with unused_bits on the [0] index, then it would be more straightforward - just like OctetStringRef.

[tarcieri]

That makes the API more awkward for callers though, just to support an AnyRef conversion.

FWIW here's one usage: https://github.com/RustCrypto/traits/blob/f517eff/elliptic-curve/src/public_key.rs#L486

That would now need a generically-sized intermediate temporary array which is one byte bigger.

[dishmaker]

We can make BitStringRef into an enum 😆

enum BitStringRef<'a> {
    UnusedBitsOutside(u8, &'a [u8]),
    UnusedBitsInside(&'a [u8]),
}

[tarcieri]

You can't convert either of those into an AnyRef though. It needs the bytes contiguous.

[RickyDaMa]

So we can't impl From<BitString> for AnyRef. Could we impl From<BitString> for Any (owned type to owned type) or impl From<BitStringRef> for Any (borrowed type to owned type)?

[tarcieri]

Yes, that'd be fine