RFC about extending defctype to support c like inline types

[Attila Lendvai]

so, take this C definition:

typedef enum {
  a = 0,
  b
} typeName;

it's a typedef where the type is not denoted by a name, but rather
it's an inline (anonymous) enum.

the symmetric equivalent of this definition is not possible in cffi.
it would look something like:

(cffi:defctype typeName (cffi:defcenum nil a b))

or maybe

(cffi:defctype typeName (cffi:cenum a b))

the issue where it comes up is in cffi/c2ffi, where the filtering
rules may filter out entries, and because the above is not possible,
the anonymous definition is given a generated name and referenced
using that name later in the defctype. it causes headache where
filters are applied to the typedef's name, and whether the anon
definition is needed depends on the outcome of those filters.

i see two ways to solve this:

 1) extend cffi:defctype (and anything else?) to support the above
    mentioned missing feature.

 2) make the c2ffi generator smarter which would be a considerable
    amount of complexity for a half-assed solution (the output will be
    full of definitions called anon-123).

i'd vote for 1), and i'd be willing to implement it, but before i get
into that, what do y'all think? some feedback would be welcome!

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Humanity can be saved only if there are enough conscious people in
the world, people who are not Christians, not Hindus, not Americans,
not Russians, who are simply conscious, and can create a climate of
consciousness around the earth.”
	— Osho (1931–1990), 'From Darkness to Light' (1985)