Reputation: 430
template <
typename input_currency_type, typename output_currency_type,
typename validation = convert_debug_policies::fast_validity_currency_type<input_currency_type>
>
fast_validity_currency_type<typename>
represents a number of static_assertions, based on the given typename (recognized with template specialization).
Note: convert_debug_policies
is a namespace.
This code compiles. However, I wondered whether typename validation
is considered OK or slightly awkward. I can imagine it being awkward because the type is actually only used for the static assertions; it is not used except for during the assignment. It would perhaps seem to be preferable to keep typename validation nameless, but I actually want to use this so that the programmer does actually know exactly what it is; especially if another debug policy (in the namespace) is given.
So my question is, is this a good way to check the validation or should I use another way to validate?
I hope I'm not too vague - Feel free to ask if I need to elaborate. Thanks!
Upvotes: 0
Views: 419
Reputation: 16070
I suppose that if you can use it only in static assertions, then everything is constexpr and you could actually do SFINAE style check on template parameter.
I'd argue that naming it in case of complicated ones gives better understanding, so the assertions seem more readable, but you can leave the name and not use it within the class. It's also possible to split the template checks into smaller named units.
Your use case sounds not like assertions nor validation, but checking whether the types fullfill some requirements.
Static assertions are used for implementing requirements as well and provide an error message which I consider a big point. An example from cppreference.. So it's mostly a design decision.
Though, one reason I'd seriously consider template-only solution is that it seems more future compatible with constraints and concepts, though that is betting against the future.
Upvotes: 1