API Stability of Alphabet Module in Release 3.2

marehr commented 3 years ago

Description

Left-overs from Release 3.1:

[x] How to do conversion between two compatible types of the same group (aminoacid, nucleotide)
- alphabet conversion currently works by converting to char and back. Is this the way we want it to be? Might have implications on the behaviour of alphabets and is thus API relevant (see https://github.com/seqan/product_backlog/issues/269#issuecomment-762196107)
- alphabet conversion is weird; dna4 = 'Y' results in Y being converted to dna15, and then to dna4 (results in 'C' instead of 'A'). dna5 and aminoacid alphabets just define one letter that is used for unknown symbols (see https://github.com/seqan/product_backlog/issues/269#issuecomment-762196107)
[x] conversion between seqan3::phred68solexa and seqan3::phred42 should be over the failure probability and not the phred scores. (see https://github.com/seqan/product_backlog/issues/269#issuecomment-804011791)
[x] The quality alphabets are not stable. (see https://github.com/seqan/product_backlog/issues/269#issuecomment-762196107)
[x] should we allow partial specialisation of seqan3::enable_aminoacid? (Undecided) (see https://github.com/seqan/product_backlog/issues/269#issuecomment-779182500)
[x] alphabet_tuple_base is ==, !=, <= commutative with indirect alphabets? (see https://github.com/seqan/product_backlog/issues/269#issuecomment-783300417)
[ ] We talked about "uint64_t is not an alphabet?" https://github.com/seqan/product_backlog/issues/200 What to do? (see https://github.com/seqan/product_backlog/issues/269#issuecomment-818703658)

Coding-issues:

[x] nucleotide_base converting constructor is under-constrained. Should require constexpr_writable_alphabet and have non-constexpr fallback. (see https://github.com/seqan/product_backlog/issues/248)
[x] convert_through_char_representation is underconstrained, should require constexpr_writable_alphabet. (see https://github.com/seqan/product_backlog/issues/248)
[x] convert_through_char_representation has SeqAn2-style wrong order of parameters (first out than in) (fixed by https://github.com/seqan/seqan3/pull/2870). (see https://github.com/seqan/product_backlog/issues/248)
[x] make union_composition require the same char_type on alternatives (see https://github.com/seqan/product_backlog/issues/248) [fixed by https://github.com/seqan/seqan3/pull/2868]

marehr commented 3 years ago

@smehringer It seems you addressed with https://github.com/seqan/seqan3/issues/2867 one of the points here. :)

Can you tick it of here if it is merged?

smehringer commented 3 years ago

Oh nice, thanks. I did not now this exists.

Since this ticket is termed release 3.2, did you already go through all of these the issues? If they all regard the alphabet API stability I still thinks it's important to avoid API breaks of known bugs.

smehringer commented 3 years ago

@smehringer It seems you addressed with seqan/seqan3#2867 one of the points here. :)

Can you tick it of here if it is merged?

done

smehringer commented 2 years ago

Done except

[ ] We talked about "uint64_t is not an alphabet?" https://github.com/seqan/product_backlog/issues/200 What to do? (see https://github.com/seqan/product_backlog/issues/269#issuecomment-818703658)

But since this is tracked in its own issue and the release is done, this issue is resolved

seqan / product_backlog

API Stability of Alphabet Module in Release 3.2 #389

Description