On 2025-04-25 at 11:14, Vladimir Grigoriev via Std-Discussion wrote:
> I am using MS VS2022 of version 17.12. Maybe in the newly vesion of MS
> VS2022 (17.13) the bug was fixed.

Could be. I have version 17.13.6


>
> Пятница, 25 апреля 2025, 11:20 +03:00 от Bo Persson via Std-
> Discussion <std-discussion_at_[hidden]>:
> On 2025-04-25 at 00:38, Vladimir Grigoriev via Std-Discussion wrote:
> > In the C++20 Standard there is written (9.7.1 Enumeration
> declarations):
> > 7 For an enumeration whose underlying type is not fixed, the
> underlying
> > type is an integral type that can represent all the enumerator values
> > defined in the enumeration. If no integral type can represent all the
> > enumerator values, the enumeration is ill-formed. It is
> implementation-
> > defined which integral type is used as the underlying type
> *except that
> > the underlying type shall not be larger than int unless the value
> of an
> > enumerator cannot fit in an int or unsigned int*. If the
> enumerator-list
> > is empty, the underlying type is as if the enumeration had a single
> > enumerator with value 0.
> > However if to run this simple program
> >
> > |#include <iostream> #include <type_traits> int main() { int vals[]
> > { 2,3,5,7,11 }; enum { N = sizeof vals / sizeof vals[0] };
> std::cout <<
> > std::boolalpha; std::cout <<
> > "std::is_same_v<std::underlying_type_t<decltype( N )>, size_t> = " <<
> > std::is_same_v<std::underlying_type_t<decltype( N )>, size_t> <<
> '\n'; }|
> >
> > |then the MS VS2022 outputs *true *though size_t is an alias for the
> > type unsigned long long and the constant value used as an
> initializer
> > of the enumerator *N *at least can fit in an object of the type
> > unsigned int.|
>
> For me it outputs false, and the IDE popup says that the type is int.
>