Is templated quantity specifications a anti-pattern?

[MiroPalmu]

I have been playing around with mp-units in my project in which I tend to write custom quantity specifications for strongly typed quantities, as in examples/storage_tank.cpp:

inline constexpr struct horizontal_length final : quantity_spec<isq::length> {} horizontal_length;

However, I might need horizontal_* strong type for number of quantity specifications. Naturally one does not want to write these separately for all kinds of quantities that might need to be horizontal, so I tried to write templated quantity specifications that model these "added properties".

Now horizontal_length would be written as:

// Note that following naming does not follow the convention from mp-units,
// in which identifiers of the custom quantity_spec and corresponding object are the same.
//
// This is due to the elaborated-type-specifier can not be class template (as far as I know),
// so it can not be used, which prevents the type and the object sharing a identifier. 
// `_type` suffix is added to the type identifier, as a workaround.

template <QuantitySpec auto WrappedQS>
struct horizontal_quantity_type final : quantity_spec<WrappedQS> {};

template <QuantitySpec auto WrappedQS>
inline constexpr horizontal_quantity_type<WrappedQS> horizontal_quantity;

inline constexpr QuantitySpecOf<isq::length> auto horizontal_length = horizontal_quantity<isq::length>;

Now to questions:

A) As I'm not 100% confident with the library abstractions, I fear that this technique might be a some sort of anti-pattern and there is nicer way to do this in mp-units. Is this there a another way?
B) Assuming these templates are ok, then is there any danger from breaking the naming convention?

[JohelEGP]

It's not OK, it's necessary. See #475.

[MiroPalmu]

Do you mean:

A) my implementation is not OK and the convention is necessary, or
B) my implementation is OK and the templates are necessary?

[JohelEGP]

Your use of templates is OK.
About the only things you might happen upon are:

• A part of an error doesn't mention what's in the <>.
• Some library user is still afraid of the <>s.

[mpusz]

There are many ways to do it, and you definitely proposed an interesting approach to this subject.

As @JohelEGP mentioned, we still have #475 to solve. This issue requires something similar as a solution. However, we initially wanted to solve it the other way around. By this, I mean that we will end up with something like my_length<horizontal> rather than horizontal<my_length>. We will have to decide one way or the other when we do more analysis on this in the future (it is planned for the 2.4.0 release).

[mpusz]

One issue with the pattern you proposed might be the fact that the code you write and the template error messages are vastly different and it is not only caused by the fact that "the elaborated-type-specifier can not be class template". You type horizontal_length, and the error message will contain horizontal_quantity_type<isq::length>, which may be harder for people to reason about.

[MiroPalmu]

Thanks for the explanations. These were not proposals per se but more of assertions that I have not misunderstood/abusing the functionality.

Just for funzies, as horizontal_length is very simple example here is more realistic templated quantity specification modeling a generic "specialized" quantities:

template <QuantitySpec auto QS, auto>
struct quantity_kind_hierarchy_leaf final : quantity_spec<QS> {};

template <QuantitySpec auto QS, auto specialization>
inline constexpr QuantitySpecOf<QS> auto specialized_quantity_spec = quantity_kind_hierarchy_leaf<QS, specialization>{};

Now this could be used to model, for example, oriented quantities:

enum class orientation { vertical, horizontal, diagonal };

template <QuantitySpec auto QS, orientation Orientation>
inline constexpr QuantitySpecOf<isq::length> auto oriented_quantity = specialized_quantity_spec<QS, Orientation>;

// Short hands:
inline constexpr auto vert = oriented_quantity<isq::length, orientation::vertical>;
inline constexpr auto hori = oriented_quantity<isq::length, orientation::horizontal>;
inline constexpr auto diag = oriented_quantity<isq::length, orientation::diagonal>;

int main() {
    using namespace si::unit_symbols;

    const QuantityOf<isq::length> auto w = 0.001 * hori[km];
    const QuantityOf<isq::length> auto h = 2.0 * vert[m];
    const QuantityOf<isq::length> auto d = sqrt(500.0) * diag[cm];


    static_assert(    QuantityOf<decltype(w), hori>);
    static_assert(not QuantityOf<decltype(w), vert>);
    static_assert(not QuantityOf<decltype(w), diag>);


    static_assert(not QuantityOf<decltype(h), hori>);
    static_assert(    QuantityOf<decltype(h), vert>);
    static_assert(not QuantityOf<decltype(h), diag>);


    static_assert(not QuantityOf<decltype(d), hori>);
    static_assert(not QuantityOf<decltype(d), vert>);
    static_assert(    QuantityOf<decltype(d), diag>);
}

Of course these suffer from the same problem that the types in compiler errors are different from the short hands.

[mpusz]

Yes, this is something similar that we want to provide to be able to model ISO 80000 and other specialized quantities.