 |
lua-l archive |
|
|
||
|
2018-03-19 18:16 GMT+02:00 Hisham <h@hisham.hm>:
> On 17 March 2018 at 03:32, Philipp Janda <siffiejoe@gmx.net> wrote:
>> I think that storing nils in tables is worth a break in backwards
>> compatibility. We should just call it Lua 6.0 and design a nicer syntax for
>> deleting keys.
>
> I fully agree with this.
>
> Lua 6.0 with nils-in-tables will be an excellent language for new
> green-field projects (scripting for the next big game, etc.) but there
> is no viable "path for compatibility" that makes a language with
> nils-in-tables fit in the Lua 5.x ecosystem.
>
> I think this is the main disconnect (among many) in this whole
> conversation: considering ecosystems.
...
> Every attempt of smoothing out the incompatibility ("strong tables",
> undef syntax hack, etc.), while well-intentioned, just adds terrible,
> terrible pitfalls to the language (e.g. "Of course you may not pass a
> strong table to old libraries").
>
> Adding nils-in-tables is a bold move and everyone seems to agree it
> moves the language forward. But it is a major breaking change, on par
> with the removal of old-style %v upvalues and introducing proper
> lexical scoping. If this is added:
>
> * it won't make sense to call this anything other than Lua 6.0
> * any attempts at making a compatibility bridge will mean that the
> entire existing Lua 5.x ecosystem is "silently broken by default" on
> Lua 6.0
If it is that revolutionary and new, then why reuse an existing term
that has been one of the mainstays of Lua?
A breaking change is unnecessary.
The value 'nil' should be what it always has been, and act like it
always has done. Instead of 'nil' changing its spots, with the devious
'undef' brought in to simulate the job 'nil' has always done, this new
animal that can be stored in tables should have a different name.
I.e. the "implementation detail" should not be an implementation
detail, it should be visible.
Lua 5.4 should have a constant of type nil called 'null' [1]. Not a
new keyword, only a new predefined value.
All the functionality aimed for with nil-in-tables can be achieved this way.
- Being of type nil, 'null' by itself tests false.
- Not being equal to nil, 'nil' is a non-hole.
- Can be preassigned to global values (or a value in any table) so
that __index can just signal an error.
[1] Or "empty" or whatever, but the name "null" fits in with JSON.