On Mon, Oct 07, 2019 at 10:24:14PM -0700, Russell Haley wrote:
> On Mon, Oct 7, 2019 at 3:12 PM Egor Skriptunoff <email@example.com>
> > On Mon, Oct 7, 2019 at 10:48 PM Petri Häkkinen wrote:
> >> > So, the motivation for the change is to move our minds from the
> >> > concept that errors return (nil,msg) to the concept that errors return
> >> > (falsy,msg). Maybe one day in the distant future we might change
> >> > that falsy to false instead of nil.
All this looks like an attempt (or goal) to provide proper exception handling in Lua.
If you think about Lua 6, one goal will be to support real exceptions and exception handlers in the language (i.e. try..catch, and possibly finally using the new "toclose" semantics supported in the VM). In which case we would no longer need to return any fail status explicitly, we would just throw an exception (passing an exception object allocated and initialized in the "try" part, so that no exception would occur to build the error object to throw and that will be caught in a matching catch handler).
Note that if C# has a very strong typing system, this has a cost on the compiler (because ensuring strict type safety is very complex, it's an NP-problem whose resolution rapidly explodes exponentially, and can result in very short programs to hang the compiler with arbitrarily large CPU time/cycles or memory/stack resources needed with lot of contexts needed in stack for backtracking). And C# still cannot assert that a program will not break the engine at runtime or will not cause the program to never halt: systems need then to implement resource monitors and watchdogs to enforce some safe limits, but Lua has still not been designed to behave correctly if resources are exhausted (the lifetime of its allocated resources is not very well managed and its garbage collector and scheduler has many unpredictable behavior when we are near the limits; this forces many systems to drop support for some APIs that cannot be safely rollbacked.)