🚀 go-pugleaf

In article <10190@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
>In article <2402@lethe.UUCP> dave@lethe.UUCP (Dave Collier-Brown) writes:
>>  Is there a technical reason for the difference in redefinition rules
>>for macros -vs- typedefs, ...?
>
>Yes.
We're waiting... holding our collective breath.
>
>Oh, you want to know what it is?  Well, consider how the compiler is
>going to parse a complex declaration containing several typedefs.
>How does it know whether you are defining the same typedef a second
>time or are just using it to help typedef something else?
>
>There's no analogous problem with #define, due to its unambiguous
>syntax that makes it clear what identifier is being defined.

This is the first good answer i've heard.  I still think it is
a (design) bug, though not by any means a new one.  

Four design options come to mind:

1. Omit typedef from the language.  People will then not be tempted to
   use it.

2. iftypedef(x), untypedef(x), and possibly retypedef(x, y).  Example:
	iftypedef(mode_t) {
		untypedef(mode_t);
		retypedef(mode_t, (char *));
	}

3. Disallow typedef definitions using typedef'ed symbols.  Allow
   typedef foo int;
   typedef foo int;
   to work.

4. Disallow
   typedef foo *foo;
   that is, self-referential typedefs.  Then allow
   typedef foo int;
   typedef foo int;
   to work, or even
   typedef u_int unsigned int;
   typedef foo unsigned int;
   typedef foo u_int;	/* synonym - it is the same */
   to work.

Option 1) is what my choice would have been at the dawn of time
(which is sometime before i knew any C).  Typedef functionality
can be obtained with #defines.  Of course, enums would also be
gone, replaced by #defines.  Option 2) is a hack on a kludge.  In
particular it makes typedef stuff look executable.  Option 3)
doesn't support "complex declarations".  Be real.  Typedefs are
nuisance synonyms that seldom have real use (the UN*X kernel is
one of those "seldom" places - nothing i've ever written outside
the kernel would benefit by them.  The kernel uses them for
simple types for portability reasons - not for itself, but for
its clients).  Option 4) doesn't actually sound too bad.  It is
probably provably completely backwards compatible.

Stephen.
...And my spelling checker agrees, it said "No errors!".