*From*: Francesco Abbate <francesco.bbt@xxxxxxxxx>*To*: luajit@xxxxxxxxxxxxx*Date*: Thu, 19 Jul 2012 11:25:12 +0200

2012/7/17 Mike Pall <mike-1207@xxxxxxxxxx>: > This change may break compatibility with existing programs using > the FFI, if you pass an enum to a non-FFI function. Hopefully this > is not very common. You may need to explicitly convert the enum to > a plain Lua number with tonumber(). Or better declare the field or > return value as an integer, if it's usually treated like a number. > > A new feature is that comparisons and arithmetic operations > automatically convert a string operand that matches an enum > constant to its value, provided the other operand is an enum. This > is the same implicit conversion that's used for storing to enum > fields/elements or passing enum arguments (already worked before): Hi all, I'm a little bit perplexed about how the overload of equality relational operators works with strings. I understand the logic and the usefulness of having enum that knows about theirs literal values. I've got myself a few situations with the GSL library where this feature could be handy but there are some issues with string comparison. I think that make the equality operator return true on string comparison does violate some very basic rules about the equality operator. For example, look at this weird behavior from your snippet example: bar.e == "AAA" '-- this is true tonumber(bar.e) == tonumber("AAA") -- this is false foo(bar.e) == for("AAA") -- can raise an error if foo is a function that take an integer This may seems unimportant but it does really undermine the underlying logic of the equality operator. But there is also a more important problem: n = 1 n == bar.e -- true bar.e == "AAA" -- true n == "AAA" -- false so the transitivity of equality comparison is violated (aaargh this looks like javascript :-) ). I believe this alone should be enough to roll back this feature about equality with strings. Of course, for the other side, equality with numbers is just fine. May be you can introduce instead something like: bar.e == ffi.enum"AAA" where ffi.enum does the required lookup but if I understood correctly this is expensive to implement. An alternative could be also: ffi.enum(bar.e) == "AAA" where ffi.enum takes the enum cdata and return its literal string representation ? These are just some quite straightforward suggestions but I strongly advice to remove the string equality feature of enumerations. Francesco

**Follow-Ups**:**Re: FFI enums are now always boxed***From:*Mike Pall

**References**:**FFI enums are now always boxed***From:*Mike Pall

- » FFI enums are now always boxed- Mike Pall
- » RE: FFI enums are now always boxed- William Adams
- » Re: FFI enums are now always boxed- Daurnimator
- » Re: FFI enums are now always boxed- Mike Pall
- » Re: FFI enums are now always boxed- Daurnimator
- » RE: FFI enums are now always boxed- Janis Britals
- » RE: FFI enums are now always boxed- William Adams
- » Re: FFI enums are now always boxed- Justin Cormack
- » Re: FFI enums are now always boxed - Francesco Abbate
- » Re: FFI enums are now always boxed- Mike Pall
- » RE: FFI enums are now always boxed- William Adams
- » Re: FFI enums are now always boxed- Leo Razoumov
- » Re: FFI enums are now always boxed- Daurnimator
- » Re: FFI enums are now always boxed- Leo Razoumov
- » Re: FFI enums are now always boxed- Vadim Peretokin
- » Re: FFI enums are now always boxed- Dimiter 'malkia' Stanev
- » Re: FFI enums are now always boxed- Daurnimator
- » Re: FFI enums are now always boxed- Mike Pall