From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) by sourceware.org (Postfix) with ESMTPS id 57FE73858C5E for ; Fri, 12 May 2023 00:15:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 57FE73858C5E 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-wr1-x431.google.com with SMTP id ffacd0b85a97d-307a8386946so2757864f8f.2 for ; Thu, 11 May 2023 17:15:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683850541; x=1686442541; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=YfhnEdYedHBEGJ4zjr+PI2aCDVqljvqS37YdhTbtq3c=; b=gEL9RsNUIopKbrkiQSJxKNEkd7UMjgJSceSkUJgPIhO0XLRUeHzE7iE73qDe4AQ0rY vk/CWeXPp7QRDC/Lot5nrTMivwsKFGWIZLpx46rQk805TkmR0YbyOacNefDKde2viD4q l7KNN9d3NQR+C2bOLtrdzkmauFJebFbkG9q7SAZuMUwLAGKoh5N9qIxazbq4zj4zXSz8 Mjxs9FQ4oYRGiB2ERk2lODdeaj8UiBbeKoIe+xSJUoEkVEaiept/BN23iyiDYawd92oI DXA4HZKuPvAvax1VOfHZJylFM2o+zXx4IKm1NuMSJYtkzrPVaoF6oFLnyjonXy2hiEeD EEeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683850541; x=1686442541; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=YfhnEdYedHBEGJ4zjr+PI2aCDVqljvqS37YdhTbtq3c=; b=f0uGfTcN/4nFQiuDN57ZsiVLWUne0BiSnUxpJRbJ+842BTJGBq43WydFW6ALXhjkdw F+ad32jn+FUMBP7zJTFsKKbB6NDTAR/AsUvG4Knt4samrfvQFjgmOMB1CBqsylooOTAz X6rG3Lz2TQQTKYbDPbYhwyW0RtVxn9TJYMOWEWbU5tB+1NzkFXMKYY2Dz6D+xVZQWUok nrE3OfqJkVXr1ENQLRLmM5XBy5sgdRMFX0NZtTu9HLwGNi60lyQt5X84758KpFoozU77 jCKZMDmnDpyBKRjrtLok8BuXPRHqKxDTu5/1CIJp6SuONHdnWRUQxecRfSwrsitWGNxX nsOw== X-Gm-Message-State: AC+VfDx7gHxAV4TZ4cNxVYPQP3lq/i3Cd9LayzN5E7eWBzRZV/vewa8E OuQf57FTdOllCeRZG0ZujdDteT6wCOc= X-Google-Smtp-Source: ACHHUZ4VFA9yrumgqbOoqAH6hUxKxcnKakTCS38glG8z1FJyPkAW4O7vALvmHWexRWlAXpzfcgAGdQ== X-Received: by 2002:a05:6000:1361:b0:306:37a2:6e56 with SMTP id q1-20020a056000136100b0030637a26e56mr14630818wrz.5.1683850540702; Thu, 11 May 2023 17:15:40 -0700 (PDT) Received: from [10.31.0.11] ([194.126.177.88]) by smtp.gmail.com with ESMTPSA id n6-20020a5d4206000000b0030630de6fbdsm21445327wrq.13.2023.05.11.17.15.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 May 2023 17:15:40 -0700 (PDT) Message-ID: <91752db5-b9db-b7e8-f1c6-f867aca2f791@gmail.com> Date: Fri, 12 May 2023 02:15:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: Wish: scoped enum To: Yair Lenga , Yair Lenga via Gcc References: Content-Language: en-US From: Gabriel Ravier In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,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: 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.