On Fri, Nov 13, 2009 at 10:53 PM, Wayne Meissner <wmeissner@gmail.com> wrote:

> I wouldn't call the first example (using constants), "BAD EXAMPLE",
> since its still a valid way to do integer constants.  Its just not as
> nice as the enum way.

Sure. Hopefully the advantages of the enum way will be clear enough
that it's not really necessary to discourage the use of integer
constants.

> 2) Assign the new Enum type to a constant
>  MyEnum = enum(:a, :b, :c)
>
> [snip]
>
> The second form however, is needed if you intend to use an enum as a
> Struct field type, for the same reason you need to do that for e.g.
> callbacks.  i.e. lexical scoping rules.

Okay, I've updated the page to mention the other forms.

But, I thought you could use the enum name as a type, even in structs.
I haven't tried it yet, but it certainly feels like that _should_ be
supported, from a library user's perspective. Even if that doesn't
work yet, "enum_type(:my_enum)" would work, right?

Or were you just showing how to use an _unnamed_ enum in a struct?

- John

P.S. Does FFI enforce the validity of values used where a particular
enum type is expected? In other words, if a function (or struct) is
expecting an enum that can be only :a, :b, or :c, would passing :d
cause it to raise an error?