At Sun, 10 May 2020 17:57:46 -0700, Larry McVoy wrote: Subject: Re: [TUHS] v7 K&R C > > > On Mon, May 11, 2020 at 10:28 AM wrote: > > > With respect to enums, there is a feature I've wanted for years: a typed > > > typedef. Saying typetdef int foo would make foo an integer, but if you > > > passed an ordinary int to something declared as foo it would be an error. > > > Even if it was an integer constant unless cast. > > Steve, I couldn't agree more, you are 100% right, this is how it should > work. I wanted to like enums because I naively thought they'd have these > semantics but then learned they really aren't any different than a well > managed list of #defines. Absolutely agreed! The lameness of typedef (and in how enum is related to typedef) is one of the saddest parts of C. (The other is the default promotion to int.) It would be trivial to fix too -- for a "new" C, that is. Making it backward compatible for legacy code would be tough, even with tooling to help fix the worst issues. I've seen far too much code that would be hard to fix by hand, e.g. some that even goes so far as to assume things like arithmetic on enum values will produce other valid enum values. Ideally enums could be a value in any native type, including float/double. > IMHO, without your semantics, enums are pretty useless, #define is good > enough and more clear. Actually that's no longer true with a good modern toolchain, especially with respect to the debugger. A good debugger can now show the enum symbol for a (matching) value of a properly typedefed variable. (In fact I never thouth that a #define macro was more clear, even before debugger support -- the debugger support just gave me a better excuse to use to explain my preference!) -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms