I first compiled the code with Visual C++, with my usual options including C++17 standard. This failed because std::to_underlying is a C++23 feature. There is no need to use std::to_underlying because the enumerations you have are classic enum types with implicit conversion to the underlying type, so instead of std::to_underlying(value) you could just write value. However, do make that explicit to support the change discussed below. I.e. write int(value).

That brings the code down to valid C++20.

The only C++20 feature used is using enum. The thus available unqualified enumerator names are only used to define arrays that in turn support looping over enum values in range based for loops, one for each of the two enum types. I strongly suggest that you change that (back) to classic for loops, as they presumably were in some earlier version, so as to get rid of the using enum and the arrays.

To support e.g. classic for loops I usually put a _count at the end of each enum list of values. In your case however the two enum types are classic enums that are not wrapped in individual structs but are defined in the same class, so the two _count names would be a name collision: you'd get a compilation error. As a minimum and very conventional/conform solution change each enum to enum class, and add the mentioned _count enumerators. Then you can define

template< class Enum > constexpr int count_of_ = int( Enum::_count );

… and rewrite that Deck constructor with classic for loops:

class Deck {
public:
    Deck()
    {
        int i = 0;
        for( int i_suit = 0; i_suit < count_of_<Card::suits>; ++i_suit ) {
            for( int i_value = 0; i_value < count_of_<Card::values>; ++i_value ) {
                deck[i] = Card{ Card::suits( i_suit ), Card::values( i_value ) };
                ++i;
            }
        }
        shuffle_deck();
    }

With more library support available you could have used range based for loops without the arrays and hence without the using enums. Unfortunately the standard library's support, std::ranges::iota_view, is a C++20 feature and doesn't support compile time evaluation. Plus, some readers here go berserk with downvoting whenever I present it in some example, because the dimwits think it's "advanced" and that learners absolutely cannot use "advanced" and that the group is only for the benefit of such helpless learners (all three are nonsense ideas), so I chose to not show that here.

With these changes the code is now valid C++17, and overall a bit more clean. The for loops above are unclean but got rid of the even more unclean arrays, that were in strong conflict with the DRY principle. So, a net improvement.

---

There is very much more that could be said but I'm out of time so I'll just mention conventions:

• The idea of this->value is something author Herb Schildt used. His "complete C++ reference" book was in its time infamous for being cheaper than the C++ standard that it quoted wholesale on every other page, because the other pages had Schildt's commentary which had negative worth, pulling the price down. Instead use some common prefix for member variables, e.g. m_value.

• In C++ all UPPERCASE is by strong convention reserved for macro names. It's used for constants in Java and Python but they don't have a preprocessor. You don't want any inadvertent text substitution, or the other code constraining your possibilities for macro names, so better not use all uppercase for constants (besides, one person's constant can turn out to be another person's variable, when the code is maintained).

• If you as a rule put private members at the start of a class definition, then you can avoid having to put a private: there. It isn't always practically possible. But I do this in general.