Named parameters of integral types through enumeration types

Question

Consider the following code:

template<int complexity>
class Widget 
{
public:
    Widget(int size);
};

int main()
{
    Widget<4> widget(12); // not easily readable if definition of Widget in some faraway header
    return 0;
}

Another try using conversion to enumeration type as named parameters:

enum ComplexityInt : int {};
enum SizeInt : int {};

template<ComplexityInt complexity>
class Widget 
{
public:
    Widget(SizeInt size);
};

int main()
{
    Widget<(ComplexityInt) 4> widget((SizeInt) 12);
    return 0;
}

Is the second example completely fine C++ code without some undesirable side effects or additional costs? And what are your thoughts about it from the style and readability perspectives?

Answer 1

There is 2 different/orthogonal things to consider (I take Rectangle as example):

• Do you want to name parameters? (as Height/Width)

Named parameters add a better expressiveness at the cost of some verbosity and extra types. Those types should probably only exist to pass argument explicitly though IMO.

Transposing Rectangle would swap height and width.

• Do you want to express a type? (as Length)

Extra types allow to be safer, at the cost of extra types, and possibly some "duplicated" functions (Length should be addable, (their product give Area), but adding Weight is also possible, duplicating the addition of their underlying type).

As const, Type might need to be propagated across the code.

• Both?

You can :-) As the concept are orthogonal. Instead of having a Height wrapping a int/double, it wraps a Length.

Answer 2

I believe those casts are undefined behavior, because those integers are outside the range of the enumeration values. From C++20 draft [expr.static.cast]/10:

If the enumeration type does not have a fixed underlying type, the value is unchanged if the original value is within the range of the enumeration values (9.7.1), and otherwise, the behavior is undefined.

I disagree that the code is unreadable without those casts. I think you're overthinking it.

With any decent editor, hovering over the class name (or ctrl-clicking to navigate to its definition) would show the definition along with the name of the complexity parameter. Same for the constructor and its size parameter.

Doing any of this casting weirdness would cause the reader to wonder what is going on, instead of just going on reading the code.

Answer 3

Let's for a moment ignore the point whether it is valid or not.

With an enum you might improve - even if I personally won't agree with that - the readability from the calling side.

But from the perspective of the code related to the Widget code itself those enum look wrong and confusing if those actually represent an integral with arbitrary values.

And if the values of complexity and size are limited to a certain range it might be a better idea to define a dedicated type for those.

If you want to go into a direction like your enum example I would use using instead.

using ComplexityInt = int;
using SizeInt = int;

template<ComplexityInt complexity>
class Widget 
{
public:
    Widget(SizeInt size);
};

int main()
{
    Widget<ComplexityInt(4)> widget( SizeInt(12) );
    return 0;
}

Answer 4

As others have already pointed out, casting is a type safety violation and should be avoided wherever possible, especially c style casts (the syntax (xxx) or xxx() is not important) because you haven't control of what the compiler is actually doing. Arguments decoration is not a valid reason to bypass the type safety of the language. Well, aside this:

Widget</*Complexity*/ 4> widget(/*Size*/ 12);

If you want some compiler support, for the int argument you could safely do this:

struct Size
{
    constexpr explicit Size(const int v) noexcept : value(v) {}
    constexpr operator int() const noexcept { return value; }
    int value;
};

template<int complexity>
class Widget 
{
public:
    Widget(Size size) {}
};

int main()
{
    //Widget<4> widget(12); // Error: 12 is not a Size
    Widget<4> widget(Size{12}); // Ok
}

The code is self explaining and I'm quite sure that this won't add overhead, the binary output will be the same. Regarding the template argument the thing is a little more delicate. Supposing that you have a finite number of possible complexities, you could do this:

enum class Complexity { min=1, mid, max, super };

template<Complexity complexity>
class Widget 
{
public:
    Widget(Size size) {}
};

int main()
{
    //Widget<4> widget(Size{12}); // Error, 4 is not a Complexity
    Widget<Complexity::super> widget(Size{12}); // Ok
}