From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x1131.google.com (mail-yw1-x1131.google.com [IPv6:2607:f8b0:4864:20::1131]) by sourceware.org (Postfix) with ESMTPS id 9F6003858CDA for ; Thu, 11 May 2023 23:58:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9F6003858CDA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-yw1-x1131.google.com with SMTP id 00721157ae682-55a5a830238so86857237b3.3 for ; Thu, 11 May 2023 16:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683849527; x=1686441527; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=sMNMa4j597AWYcviuyM2vvcb+6mHbsori4OD+f4HM1A=; b=gQvcT01jn3uj3/WGQQOKpVNY6dOltn3/uQDjupHWhFY99DkAmRt83oTxqIDdKKhNZ0 L34cwtJLmVY8XPmX+l3AphRs6gqtxs8CWKlQN034aNPKAR0G4qduZEv0ZQrWjrbRRqrL NgeR558SZiaYGu50Q1YmcG+r+2wwkNthpN8zMfH9mB937LsoR2QSM+nFJxaj/gtp5Eib Ac4n+XuwTdDp4goJUhQOVVsIU7ec3BC/JyYvLRxgmfXoVxPgQUdPdqA7iorcnzw60UJG 4ZvCUQUCMjUixmHrKNgdUHn+jsOwSE89cE4NwsRLJsK1H1xkK6A9vSkV4yv2WSkMeTkt TORw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683849527; x=1686441527; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=sMNMa4j597AWYcviuyM2vvcb+6mHbsori4OD+f4HM1A=; b=JAwUeYEuL4pJuLotQDQxz5tvOAHbbpNaoP0fWrKgXm1ew8EQ+m7sjtp84lYaN1tLE5 RrJ8ZrzmEx5vHI86kaUsPGqxkLqBW/KxA04iOx5jBIYZG4aedQwHsfb8+ZLOUsQXTwhx W3Q8DsTXVXAl7IALgaD8b0lo/+ITpglOFvy8IXb809dJHygT+LNgBL1vXY13BjsTQa9J 5M+xDFrKYh6Qwv3sg8K2LwsOzHXQ4EbE0yVq1MXidb9mp0v8Np+hc+AawT7j5OeSdqVF vLqg5UrLZ3bMWJsnFOCz0McCCWDY1o3qjgF0hHwuejeLVqpUCLUziplXbfARPYpDy10g Bk3w== X-Gm-Message-State: AC+VfDyZMyL/0vuJamZUZK9qr+hFC/HK3eCFFf5TIyERdrP1YpcSziOI gepIb9kEx6iD6HzeJ4SqTLWxTV7Q1jzId9cIbmKSAAtpYmg= X-Google-Smtp-Source: ACHHUZ70d9vH1vtm6RazNXuvAhNPJFVpneVHV0Q+ySeP8PXQDqLN/qYxMKht8XWOYoWCb2SWcwnFVmIfuQFW8gqFRm8= X-Received: by 2002:a81:8445:0:b0:55c:67df:6700 with SMTP id u66-20020a818445000000b0055c67df6700mr24672771ywf.19.1683849526658; Thu, 11 May 2023 16:58:46 -0700 (PDT) MIME-Version: 1.0 From: Yair Lenga Date: Thu, 11 May 2023 19:58:35 -0400 Message-ID: Subject: Wish: scoped enum To: Yair Lenga via Gcc Content-Type: multipart/alternative; boundary="000000000000e449c405fb73c450" X-Spam-Status: No, score=0.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --000000000000e449c405fb73c450 Content-Type: text/plain; charset="UTF-8" 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 --000000000000e449c405fb73c450--