wiki: document concepts as doxygen interfaces #72
Description
I good workaround for doxygen not supporting concepts seems to be excluding them from the documentation build via \cond and \nocond and then just defining them via the interface command. It is also possible to define the required functions on this concept as members or related functions of that concept.
Then we can also mark other types as \implements concept_name and have concepts that refine other concept specify \extends other_concept. This should provide for really nice documentation!
Here is an example of the alphabet_concept:
/*!\interface seqan3::alphabet_concept <>
* \brief The generic alphabet concept that covers most data types used in ranges.
* \ingroup alphabet
*
* The requirements for this concept are given as related functions and metafunctions.
* Types that satisfy this concept are shown as "implementing this interface".
*/
/*!\fn auto seqan3::to_char(alphabet_concept const c)
* \brief Returns the alphabet letter's value in character representation.
* \relates seqan3::alphabet_concept
* \param c The alphabet letter that you wish to convert to char.
* \returns The letter's value in the alphabet's char type (seqan3::underlying_char).
* ...
*/
//!\cond
template <typename t>
concept bool alphabet_concept = requires (t t1, t t2)
{
// StL concepts
requires std::is_pod_v<t> == true;
requires std::is_swappable_v<t> == true;
// static data members
alphabet_size<t>::value;
// conversion to char and rank
{ to_char(t1) } -> underlying_char_t<t>;
{ to_rank(t1) } -> underlying_rank_t<t>;
{ std::cout << t1 };
// assignment from char and rank
{ assign_char(t1, 0) } -> t &;
{ assign_rank(t1, 0) } -> t &;
{ assign_char(t{}, 0) } -> t &&;
{ assign_rank(t{}, 0) } -> t &&;
// required comparison operators
{ t1 == t2 } -> bool;
{ t1 != t2 } -> bool;
{ t1 < t2 } -> bool;
{ t1 > t2 } -> bool;
{ t1 <= t2 } -> bool;
{ t1 >= t2 } -> bool;
};
//!\endcond@xenigmax can you do this for the existing concept definitions (alphabet, nucleotide...)? For the general concepts (range, core...) there doesn't need to be any function or requirement definition, but the correct inheritance/extension would be nice.