public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Arsen Arsenović" <arsen@aarsen.me>
To: Yair Lenga <yair.lenga@gmail.com>
Cc: gcc@gcc.gnu.org
Subject: Re: Wish: scoped enum
Date: Fri, 12 May 2023 02:11:41 +0200	[thread overview]
Message-ID: <86h6si2ymw.fsf@aarsen.me> (raw)
In-Reply-To: <CAK3_KpP6K42per8+JVDys9GEsKG2BaY0waFnibgTVafe29FQig@mail.gmail.com>

[-- 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 --]

  reply	other threads:[~2023-05-12  0:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-11 23:58 Yair Lenga
2023-05-12  0:11 ` Arsen Arsenović [this message]
2023-05-12  0:15 ` Gabriel Ravier
2023-05-12 10:02   ` Yair Lenga
2023-05-12 10:05   ` Yair Lenga

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86h6si2ymw.fsf@aarsen.me \
    --to=arsen@aarsen.me \
    --cc=gcc@gcc.gnu.org \
    --cc=yair.lenga@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).