 |
lua-l archive |
|
|
||
|
Obviously, the introduction of 'undef' as a new keyword is only fully compatible with existing (bug-free) Lua code when it does not use undef at all, or when it is used as a read-only global variable that is never assigned (which is a very brittle assumption). Any other use of undef will be incompatible. There are largely three cases:1. Compile-time incompatibilities, such as local undef = foo, function undef() end, undef = bar, table.undef = baz, etc. Any existing code that does that will have to be fixed.2. Silently broken code. Any existing code that does the equivalent of _ENV['undef'] = foo with a subsequent use of an equivalent of table.foo = undef, will silently do something unexpected by its authors.3. Piece-wise silently broken code, which is the result of case (1) fixed in some way where undef was previously defined as a non-nil entity, and the code left with the equivalent of table.foo = undef, which was originally written under the assumption that undef is something non-nil. Given the nature of the typical use of Lua, where scripts normally are not loaded ahead of time and old code may be floating around for a very long time, this can be quite nasty.I am not convinced that the noble goal of "compatibility" of'undef between 5.3 and 5.4 outweighs these compatibility problems.