Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #162867

Re: redeclaration of enumerators?

Show all headers | View raw

On 29/09/2021 14:36, David Brown wrote:
> On 29/09/2021 00:31, Bart wrote:
>> On 28/09/2021 22:57, Keith Thompson wrote:
>>> John Bode <jfbode1029@gmail.com> writes:
>>>> On 9/27/21 12:39 PM, Thiago Adams wrote:
>>>>> I was wondering if we have some reason to
>>>>> disallow redeclaration of identical (name/value) enumerators.
>>>>> enum E1 {  A = 1 };
>>>>> enum E2 {  A = 1 };
>>>>
>>>> Unlike structs and unions, each enum type is not its own
>>>> namespace and enumeration constants belong to the "ordinary
>>>> identifiers" namespace.
>>>>
>>>> The question is how you would disambiguate the two definitions
>>>> of A - there's no equivalent to the '.' or '->' operators for
>>>> enums.  There's no way to easily say "I'm talking about the A
>>>> defined for enum E1, not the A defined for enum E2".
>>>>
>>>> Can't rely on type inference in assignments; enums are just an
>>>> incredibly weak abstraction in C. There's no range checking
>>>> such that you can only assign one of the defined enumeration
>>>> constants to an object of that enum type.
>>>>
>>>> You'd either need to introduce a C++-style scoping operator like
>>>> E1::A or E2::A, or you'd need to radically revamp and strengthen
>>>> enum semantics.  And in the process you'd likely lose some capability
>>>> that people find incredibly useful, such as bitwise-ORing enumeration
>>>> constants together.
>>>>
>>>> enums in C are little more than a way to create symbolic constants for
>>>> integer values.  They are not really *enumerated types* like you
>>>> find in other languages.
>>>
>>> I think the suggestion is to allow duplicate names only if both the name
>>> and the value happen to match.  Thiago's example:
>>>
>>>       enum E1 {  A = 1 };
>>>       enum E2 {  A = 1 };
>>>
>>> would be valid, but changing one of the values:
>>>
>>>       enum E1 {  A = 1 };
>>>       enum E2 {  A = 2 };
>>>
>>> would result in a constraint violation.  (I presume the same would apply
>>> if the values are chosen implicitly.)
>>>
>>> There's no fundamental reason this couldn't be done, but I don't think
>>> it's useful enough to justify a language change.  If you want two enum
>>> types to share values, you can define them as a single type.
>>>
>>> (C++ does have an "enum class" feature which, among other things, allows
>>> for duplicate names, but then you always need to refer to "E1::A"
>>> whether it's ambiguous or not.)
>>
>> That's surprising. With stricter typing, you think it would figure out
>> that the A here:
>>
>>      enum E2 x = A;
>>
>> needs to be E2::A.
>>
> 
> It is not remotely surprising - in order to be able to use identifiers
> within a nested code structure (I'm using that as a general term, not
> just "struct") of some sort, you need to be "inside" the structure, in
> the scope of a "using" clause, or you need to give the qualified name.

Yeah, you're right. It would be tricky anyway, because it can't be 
sorted using normal name resolution rules, since it relies on type info 
which may not be dealt with until a subsequent stage.

But also, you could have this:

    enum E2 {A=1, B, C};
    enum E2 A, B;

        A = E2::C
        B = A;

Is the RHS the variable A (which contains 3), or is it intended to be 
E2::A, which is 1?

(This makes me feel better about my own stuff, which can have 'closed' 
enums like C, but they need qualifying too:

   enum colours = (red, green, blue)
   enum lights  = (red, amber, green)

   colours A = colours.green        # can't use A = green)

> Maybe new parsing rules for C++ can be figured out that would allow "E2
> X = A;", or at least "E2 x { A };".  I don't see how it could easily be
> done, however, without a lot of complications and side-effects.  This
> isn't an ad-hoc language where you can just make up the rules as you go
> along without a care of how they affect other parts of the language.


I don't make up ad-hoc languages; they have to work. You can only cut a 
few minor corners.

But I understand parsing C++ can requires some ingenuity anyway, because 
the language is so complex and with unexpected and ambiguous 
interactions between features.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

redeclaration of enumerators? Thiago Adams <thiago.adams@gmail.com> - 2021-09-27 10:39 -0700
  Re: redeclaration of enumerators? John Bode <jfbode1029@gmail.com> - 2021-09-28 16:21 -0500
    Re: redeclaration of enumerators? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-28 14:57 -0700
      Re: redeclaration of enumerators? Thiago Adams <thiago.adams@gmail.com> - 2021-09-28 15:23 -0700
        Re: redeclaration of enumerators? David Brown <david.brown@hesbynett.no> - 2021-09-29 15:23 +0200
        Re: redeclaration of enumerators? Mark Bluemel <mark.bluemel@gmail.com> - 2021-09-30 01:15 -0700
      Re: redeclaration of enumerators? Bart <bc@freeuk.com> - 2021-09-28 23:31 +0100
        Re: redeclaration of enumerators? David Brown <david.brown@hesbynett.no> - 2021-09-29 15:36 +0200
          Re: redeclaration of enumerators? Bart <bc@freeuk.com> - 2021-09-29 15:03 +0100
            Re: redeclaration of enumerators? David Brown <david.brown@hesbynett.no> - 2021-09-29 16:46 +0200
              Re: redeclaration of enumerators? Bart <bc@freeuk.com> - 2021-09-29 16:08 +0100
                Re: redeclaration of enumerators? David Brown <david.brown@hesbynett.no> - 2021-09-29 20:14 +0200
                Re: redeclaration of enumerators? Thiago Adams <thiago.adams@gmail.com> - 2021-09-29 13:37 -0700
                Re: redeclaration of enumerators? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-29 18:25 -0700
                Re: redeclaration of enumerators? David Brown <david.brown@hesbynett.no> - 2021-09-30 12:45 +0200
                Re: redeclaration of enumerators? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-09-30 07:36 -0700
                Re: redeclaration of enumerators? David Brown <david.brown@hesbynett.no> - 2021-10-01 09:20 +0200
                Re: redeclaration of enumerators? Bart <bc@freeuk.com> - 2021-10-01 11:24 +0100
                Re: redeclaration of enumerators? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-10-01 04:49 -0700
                Re: redeclaration of enumerators? Bart <bc@freeuk.com> - 2021-10-01 13:06 +0100
                Re: redeclaration of enumerators? Tony Oliver <guinness.tony@gmail.com> - 2021-10-01 05:24 -0700
                Re: redeclaration of enumerators? Bart <bc@freeuk.com> - 2021-10-01 13:32 +0100
                Re: redeclaration of enumerators? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-10-01 05:32 -0700
                Re: redeclaration of enumerators? Bart <bc@freeuk.com> - 2021-10-01 13:43 +0100
                Re: redeclaration of enumerators? Mark Bluemel <mark.bluemel@gmail.com> - 2021-10-01 06:13 -0700
                Re: redeclaration of enumerators? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-10-01 06:29 -0700
                Re: redeclaration of enumerators? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-10-01 15:30 +0100
                Re: redeclaration of enumerators? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-10-01 08:28 -0700
                Re: redeclaration of enumerators? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-10-01 17:08 +0100
                Re: redeclaration of enumerators? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-10-01 15:12 -0700
                Re: redeclaration of enumerators? David Brown <david.brown@hesbynett.no> - 2021-10-01 15:37 +0200
                Re: redeclaration of enumerators? Bart <bc@freeuk.com> - 2021-10-01 15:30 +0100
                Re: redeclaration of enumerators? David Brown <david.brown@hesbynett.no> - 2021-10-01 19:12 +0200
                Re: redeclaration of enumerators? Bart <bc@freeuk.com> - 2021-10-01 19:06 +0100
                Re: redeclaration of enumerators? David Brown <david.brown@hesbynett.no> - 2021-10-01 15:32 +0200
                Re: redeclaration of enumerators? Bart <bc@freeuk.com> - 2021-10-01 15:38 +0100
                Re: redeclaration of enumerators? Bart <bc@freeuk.com> - 2021-10-01 17:40 +0100
                Re: redeclaration of enumerators? Bart <bc@freeuk.com> - 2021-10-02 12:16 +0100
                Re: redeclaration of enumerators? David Brown <david.brown@hesbynett.no> - 2021-10-02 15:34 +0200
                Re: redeclaration of enumerators? Bart <bc@freeuk.com> - 2021-10-02 15:16 +0100
                Re: redeclaration of enumerators? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-01 13:58 -0700
                Re: redeclaration of enumerators? Richard Damon <Richard@Damon-Family.org> - 2021-10-01 17:21 -0400
                Re: redeclaration of enumerators? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-10-01 14:56 -0700
                Re: redeclaration of enumerators? David Brown <david.brown@hesbynett.no> - 2021-10-02 12:21 +0200
                Re: redeclaration of enumerators? scott@slp53.sl.home (Scott Lurndal) - 2021-09-30 14:47 +0000
                Re: redeclaration of enumerators? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-09-30 10:10 -0700
                Re: redeclaration of enumerators? David Brown <david.brown@hesbynett.no> - 2021-10-01 09:24 +0200
            Re: redeclaration of enumerators? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-09-29 12:43 -0700
    Re: redeclaration of enumerators? Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-29 03:40 +0000

csiph-web