Arsen, Gabriel,

Thanks for your feedback. I read through the n2347 article, and I believe
that your feedback is to leverage the C++ 'enum struct' grammer. As you can
tell, I'm not a C++, and and I did not know that the 'SCOPED enum' is
already available for using 'enum class' or 'enum struct'. Leveraging the
work done in C++, and keeping C/C++ compatible.

Given that this is already implemented inside C++, looking for advice on
the best path to implement it in gcc C ? I'm not familiar with the
internals of C/C++, can the C++ behavior/grammar can be simply "enabled"
(with a flag) for "C", or does it require reimplementation for the "C"
front end. I have experience in "C" - does anyone know where in the source
tree one should look to try to implement myself ? I know gcc is "layered" -
shared backends, optimizer, code generation - so that change should be (in
theory) only in the "C" front end.

Thanks again for the useful feedback.

Yair

On Thu, May 11, 2023 at 8:15 PM Gabriel Ravier <gabravier@gmail.com> wrote:

> On 5/12/23 01:58, Yair Lenga via Gcc wrote:
> > Hi,
> >
> > I wonder if it will be possible to add support for "scoped" enum to GCC.
> > The current C standard has one name space for all enums, and different
> name
> > space for the members of each "struct". As a result, possible to say
> >
> > struct foo { int a } ;
> > struct bar { double a };     // This is different 'a', different type
> >
> > But illegal to to (ignoring the conversion to use all upper for enum).
> >
> > enum a { u, v } ;
> > enum b { v, w } ;             // can not do this, as 'v' must be distinct
> >
> > One annoying side effect is that any package/module creating an enum has
> to
> > worry about namespace collision with everyone else in the world. Common
> > practices include distinct prefixes, similar to the way different
> libraries
> > use distinct prefixes to avoid function name collision. This solution is
> > far from perfect and leads to excessive long enum name.
> >
> > A reasonable wish list - add a magic keyword that will place the enums
> into
> > a scope, so that the following work:
> >
> > SCOPED enum shirt_sz { small, medium, large } ;
> > SCOPED enum shoe_sz { small, medium, medium_wide, large, xlarge } ;
> >
> > enum shirt_sz tshift_size = shift_sz.medium ;
> > enum shoe_siz boot_size = shoe_sz.xlarge ;
> >
> > Not perfect, but not complex, will make enum reusable across many
> scenario,
> > where they are currently hard to implement - because of namespace
> conflict
> > - between system header and user headers, between different packages.
> >
> > A smart compiler can also alert when "types" are mixed (assign value from
> > shift_sz to a variable of type shoe_sz). Not critical - as my
> understanding
> > is that this is not enforced today. For the case that an enum symbol is
> > distinct (in the current compilation unit), the compiler can allow using
> it
> > without the namespace - practically falling back into current behavior.
> >
> > Feedback ? Anyone know how to get a prototype into gcc ? How one get
> > approval for such "extensions".
> >
> > Yair
>
> You may wish to learn about
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf -
> although of course this isn't available in C right now, but the addition
> of a differing, syntactically incompatible while substantially
> overlapping feature to C to reproduce the same functionality as `enum
> class` seems far more unlikely to occur than the addition of `enum
> class` to C.
>
>