Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Thiago Adams Newsgroups: comp.lang.c Subject: Re: enum sets Date: Thu, 29 Aug 2024 08:44:45 -0300 Organization: A noiseless patient Spider Lines: 125 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Thu, 29 Aug 2024 13:44:45 +0200 (CEST) Injection-Info: dont-email.me; posting-host="f80b8b85f3cf443035f3bd640f6489b4"; logging-data="4150959"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18+LpYMPUJWQgkJBrW9eVGKJVh7ixlfL/k=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:G7pjCp6Vh620XImP+VzKAxwrkxg= Content-Language: en-US In-Reply-To: Bytes: 3806 On 29/08/2024 08:34, Thiago Adams wrote: > On 29/08/2024 04:33, David Brown wrote: >> On 29/08/2024 01:42, Thiago Adams wrote: >>> I am wondering how useful would be to have enum sets. >>> >>> Let´s say you have a function that accepts only monospaced fonts.Then >>> you can use enum monospaced_font_type. Or a switch case where you >>> need to check all and only monospaced_font_type. >>> >>> But at same type you can store at same object monospaced_font_type or >>> font_type. >>> >>> enum font_type >>> { >>>      enum monospaced_font_type >>>      { >>>          CASCADIA_FONT, >>>      }, >>>      ARIAL_FONT >>> }; >>> >>> This could be arranged in any way. >>> >> >> I think this could have some use-cases, but I suspect that often you >> would want to have separate enumerations defined first, then combine >> them with a sum type (aka variant, tagged union, discriminated type, >> etc.). >> >> >> enum monospaced_font_type { >>      cascadia >> }; >> >> enum proportional_font_type { >>      arial >> }; >> >> typedef struct { >>      enum { is_monospaced_font_type, is_proportional_font_type } tag; >>      union { >>          enum monospaced_font_type mf; >>          enum proportional_font_type pf; >>      } >> } font_type; >> > > One of my motivations was that I have a big enum and sometimes I need to > check in switch cases all values of some type. > > For instance, let's say > > enum E {A, B, C, D /*until Z*/}; > > And I need to check a subset  for instance  A, B > > To have a warning if I miss some item I need to include all cases. > > void f(enum E e) > { >    switch(e) >    { >      case A: >      case B: >      break; > >      case C: >      //..Z >      break; >    } > } > //warning you missing D case. > > > The  problem this is not practical when  the number of items is too big. > Using default:break; makes it practical but then the warning disappears. > > > With this enum set idea the code would be > > enum E { >    enum Subset {A, B} >    , >    C, >    D /*until Z*/ > }; > > void f(enum Subset e) > { >    switch(e) >    { >      case A: >      break; >    } //warning you miss case  B > } > > Another motivation could be error code sets. But I think this may not be practical. (So this was not my motivation) enum error { enum func1_error { E1, E2 } enum func2_error { E1, E3 } } enum func2_error func2(); enum func2_error error = func2(); switch (error) { case E1: case E3: break; }