Is there an intention to add library concepts in place of the current named requirements?
There's admittedly some challenges in doing so, but I enjoy the benefits of clearer error messages and simpler overload sets.
e.g.
template <typename E>
concept encoding =
(requires() {
// One state type
typename E::state;
} ||
requires() {
// OR distinct state types
typename E::encode_state;
typename E::decode_state;
}) &&
requires(E encoding,
encode_state_t<E> enc_state,
decode_state_t<E> dec_state,
range_archetype<convertible_to_archetype<code_point_t<E>>> cp_in_range,
range_archetype<convertible_to_archetype<code_unit_t<E>>> cu_in_range,
range_archetype<assignable_from_archetype<code_point_t<E>>> cp_out_range,
range_archetype<assignable_from_archetype<code_unit_t<E>>> cu_out_range,
handler_archetype handler) {
{ E::max_code_points } -> convertible_to<size_t>;
{ E::max_code_units } -> convertible_to<size_t>;
{ encoding.encode_one(cp_in_range, cu_out_range, handler, enc_state) };
{ encoding.decode_one(cu_in_range, cp_out_range, handler, dec_state) };
};Such a definition won't be perfect because we can't be certain that encode_one() will be valid without knowing the exact range type that will be used until we actually call it, but one can make a very close approximation using concept archetypes.
Is there an intention to add library concepts in place of the current named requirements?
There's admittedly some challenges in doing so, but I enjoy the benefits of clearer error messages and simpler overload sets.
e.g.
Such a definition won't be perfect because we can't be certain that
encode_one()will be valid without knowing the exact range type that will be used until we actually call it, but one can make a very close approximation using concept archetypes.