* Wish: scoped enum @ 2023-05-11 23:58 Yair Lenga 2023-05-12 0:11 ` Arsen Arsenović 2023-05-12 0:15 ` Gabriel Ravier 0 siblings, 2 replies; 5+ messages in thread From: Yair Lenga @ 2023-05-11 23:58 UTC (permalink / raw) To: Yair Lenga via Gcc [-- 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Wish: scoped enum 2023-05-11 23:58 Wish: scoped enum Yair Lenga @ 2023-05-12 0:11 ` Arsen Arsenović 2023-05-12 0:15 ` Gabriel Ravier 1 sibling, 0 replies; 5+ messages in thread From: Arsen Arsenović @ 2023-05-12 0:11 UTC (permalink / raw) To: Yair Lenga; +Cc: gcc [-- 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 --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Wish: scoped enum 2023-05-11 23:58 Wish: scoped enum Yair Lenga 2023-05-12 0:11 ` Arsen Arsenović @ 2023-05-12 0:15 ` Gabriel Ravier 2023-05-12 10:02 ` Yair Lenga 2023-05-12 10:05 ` Yair Lenga 1 sibling, 2 replies; 5+ messages in thread From: Gabriel Ravier @ 2023-05-12 0:15 UTC (permalink / raw) To: Yair Lenga, Yair Lenga via Gcc 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Wish: scoped enum 2023-05-12 0:15 ` Gabriel Ravier @ 2023-05-12 10:02 ` Yair Lenga 2023-05-12 10:05 ` Yair Lenga 1 sibling, 0 replies; 5+ messages in thread From: Yair Lenga @ 2023-05-12 10:02 UTC (permalink / raw) To: Gabriel Ravier; +Cc: Yair Lenga via Gcc [-- 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. > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Wish: scoped enum 2023-05-12 0:15 ` Gabriel Ravier 2023-05-12 10:02 ` Yair Lenga @ 2023-05-12 10:05 ` Yair Lenga 1 sibling, 0 replies; 5+ messages in thread From: Yair Lenga @ 2023-05-12 10:05 UTC (permalink / raw) To: GCC mailing list; +Cc: Arsen Arsenović, Gabriel Ravier [-- 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. > > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-05-12 10:05 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-05-11 23:58 Wish: scoped enum Yair Lenga 2023-05-12 0:11 ` Arsen Arsenović 2023-05-12 0:15 ` Gabriel Ravier 2023-05-12 10:02 ` Yair Lenga 2023-05-12 10:05 ` Yair Lenga
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).