Wish: scoped enum

Wish: scoped enum

[Yair Lenga]

[-- Attachment #1: Type: text/plain, Size: 1858 bytes --]

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

Re: Wish: scoped enum

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 2293 bytes --]

Hi,

Yair Lenga via Gcc <gcc@gcc.gnu.org> writes:

> 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".

I'd suggest, if you choose to implement this, to imitate what C++ does
for these, maybe even propose it for the standard.  There's already
established syntax and semantics.

It would certainly be nice to have such a thing in C.

Have a lovely evening.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: Wish: scoped enum

[Gabriel Ravier]

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.

Re: Wish: scoped enum

[Yair Lenga]

[-- Attachment #1: Type: text/plain, Size: 3598 bytes --]

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.
>
>

Re: Wish: scoped enum

[Yair Lenga]

[-- Attachment #1: Type: text/plain, Size: 3681 bytes --]

rsen, 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.

Once there is implementation - where should it get posted for
feedback/review ?

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.
>
>