$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Ivan Matek (libbooze_at_[hidden])
Date: 2025-06-12 11:50:27
On Thu, Jun 12, 2025 at 1:37â¯PM Andrey Semashev via Boost <
boost_at_[hidden]> wrote:
>
> > I am mostly talking about conceptual meaning of enum: set<int> is not
> int.
>
> The standard defines enumerations as "a distinct type with named
> constants". That is, its a way to define a number of named constants and
> associate them with a type. The standard then goes on to say that an
> enumeration has an underlying type. It doesn't say that the set of
> values of the enum type is limited to the named constants (as it says
> e.g. for bool); other values, as long as those values are representable
> by the underlying type, are implicitly allowed. So when you're saying an
> enum cannot have values other than the named constants (I'm assuming
> that's what you mean by "set<int>" above), you are talking about one
> particular usage scenario of the enum, where you simply don't use values
> other than the named constants. That's not the only valid usage
> scenario, and enums implementing bit masks are not a misuse of enums.
>
> Yeah when I sent an email I realized I should have been more precise. I
know what current state of language is, I just think it is bad, and I try
to avoid confusing/bad parts of C++.
Again according to me, I am not trying to convert you, I understand this is
personal preference.
Sankel proposal I linked explains in detail what I am talking about:
In C++ enum is a "union" of different things(not to be confused with union
as language construct).
I dislike that since it makes reasoning harder, i.e. it would be better if
that functionality was split.
So in my ideal world flag is a language feature and enum is a language
feature, so | is not allowed on enum values.
Sankel proposal wanted to add [[exhaustive]] that beside ugly syntax is
something I would like to see in the language.