The skills for ++ / -- don't compile

[CelticMinstrel]

I'm using MSVC, and it complains it can't convert the underlying type to the named type. Looking at the definition, I see it really is doing that, which seems wrong.

[stellarpower]

Not sure if the same, but on g++, I can't use these because of ambiguities:

using U = NamedType<unsigned, struct UTag, Arithmetic>;
for (U i = U(0); i < U(10); i++)
    ;

In function 'int main()':
error: request for member 'operator++' is ambiguous
|     for (U i = U(0); i < U(10); i++)
|                                  ^~
In file included from ..../NamedType/include/NamedType/named_type.hpp:5,
..../NamedType/include/NamedType/underlying_functionalities.hpp:43:26: note: candidates are: 'constexpr T fluent::PostIncrementable<T>::operator++(int) [with T = fluent::NamedType<unsigned int, main()::UTag, fluent::Arithmetic>]'
|     FLUENT_CONSTEXPR17 T operator++(int)
|                          ^~~~~~~~
..../NamedType/include/NamedType/underlying_functionalities.hpp:29:27: note:                 'constexpr T& fluent::PreIncrementable<T>::operator++() [with T = fluent::NamedType<unsigned int, main()::UTag, fluent::Arithmetic>]'
|     FLUENT_CONSTEXPR17 T& operator++()
|                           ^~~~~~~~

It appears for some reason that it is struggling to determine whether it should call the pre-increment or post-increment version. I'd have to guess that it can resvole to a base class through either route, and that it must find one specific class to try and call the increment on before then picking between the pre- and post-increment version, asI guess the extraneous int parameter is a little but of a hack in the language, that may need normal overload rules to be carried out first. But it's just a guess.

For now, I can work around using i += U(1); a literal operator also helps make this more readable (main place it's being used is in hand-rolled loops, so this helps a lot. E.g.
for (MyLongNamedType i = 0_M; i <= 10_M; i += 1_M)