API Stability of Alphabet Module in Release 3.2

[marehr]

Description

Left-overs from Release 3.1:

• 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 API Stability of Alphabet Module #269 (comment))
  • 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 API Stability of Alphabet Module #269 (comment))
• conversion between seqan3::phred68solexa and seqan3::phred42 should be over the failure probability and not the phred scores. (see API Stability of Alphabet Module #269 (comment))
• The quality alphabets are not stable. (see API Stability of Alphabet Module #269 (comment))
• should we allow partial specialisation of seqan3::enable_aminoacid? (Undecided) (see API Stability of Alphabet Module #269 (comment))
• alphabet_tuple_base is ==, !=, <= commutative with indirect alphabets? (see API Stability of Alphabet Module #269 (comment))
• We talked about "uint64_t is not an alphabet?" uint64_t is not an alphabet? #200 What to do? (see API Stability of Alphabet Module #269 (comment))

Coding-issues:

• nucleotide_base converting constructor is under-constrained. Should require constexpr_writable_alphabet and have non-constexpr fallback. (see General alphabet cleanup #248)
• convert_through_char_representation is underconstrained, should require constexpr_writable_alphabet. (see General alphabet cleanup #248)
• convert_through_char_representation has SeqAn2-style wrong order of parameters (first out than in) (fixed by [FIX] the in/out parameter order of convert_through_char_representation seqan3#2870). (see General alphabet cleanup #248)
• make union_composition require the same char_type on alternatives (see General alphabet cleanup #248) [fixed by https://github.com/[FIX] Restrict seqan3::alphabet_variant. seqan3#2868]

[marehr]

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

Can you tick it of here if it is merged?

[smehringer]

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]

@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]

Done except

• We talked about "uint64_t is not an alphabet?" uint64_t is not an alphabet? #200 What to do? (see API Stability of Alphabet Module #269 (comment))

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