`Seq<text::Dna>` codec should be zero cost alias to `[u8]`

[jeff-k]

The text::* codecs are meant to be u8 representations of bases/residues in utf-8. A Seq<...> of a text codec is effectively a Bstr type.

The representation of a Seq<text::Dna> should be dereferenceable as a [u8] and vice-versa without copying.

[DaGaMs]

I've run into what I think is a related issue. I thought I'd store some DNA sequence as Seq<Dna>, because I will need to do reverse complements etc, and the memory-efficient 2-bit encoding is appealing. However, in order to work with e.g. bsalign, I need sequences as [u8]. What's the best way to make this work, ie use bio_seq's Seq but access the stored sequence as [u8] where necessary? Currently, I am copying to String via into(), this seems quite inefficient...

[jeff-k]

Hey, I'm hitting up against this limitation right now too. I want to make python bindings and let the user load in a memory mapped fasta as a [u8] that can be transparently treated as a Seq<text::Dna>. Converting between an 8-bit Seq<text::Dna> and 2-bit Seq<Dna> will never be copy-free, but there's some cool SIMD tricks I want to put in and implementing them on Seq<text::Dna> will be a lot cleaner.

It's going to be tricky, but I think the way to do this without introducing any indirection or overhead is:

• define a SeqStorage trait, much like the KmerStorage with an associated type for the underlying storage type's slice
• implement this trait for Vec<u8> and BitVec
• make a SeqStorage associated with the Codec types, so:

impl Codec for Dna {
    type SeqStorage = Bv; // for the 2-bit Dna encoding Bv is the current type alias for BitVec<usize>
    // ...
}

impl Codec for AsciiDna { // actually called text::Dna
    type SeqStorage = Vec<u8>;
    // ...
}

• and then re-implement Seq and SeqSlice to delegate their operations to the specific SeqStorage implementations.

This will be monomorphised at compile time, so won't introduce any additional run-time overhead. It's consistent with the design of the Kmer type, too.

And it also makes us agnostic to using bitvec for the underlying storage type- we'd have the option for other bit packing storage types without introducing any complexity to the API.