lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]



> On Oct 5, 2019, at 1:35 PM, Phil Leblanc <philanc@gmail.com> wrote:
> 
> 1)  I understand that 'fail' is not a literal value (such as 'true'),
> and not a reserved word.  Is it correct to say It is a variable name
> which happens to be undefined, and so evaluates to nil?
> 
> 2) Does the Lua team encourage C extension developers to use
> luaL_pushfail(L) instead of lua_pushnil(L)?  if yes, maybe
> luaL_pushfail should be documented in the manual, section 5.
> 
> 3) Do you encourage Lua library developers to update their libraries
> and start using  use the idiom "return fail, msg" in case of error
> (instead of "return nil, msg")?
> 
> If yes, I would recommend a big warning somewhere in the manual
> (where?) and also in every "new style" library documentation:  If such
> a library is used in a program which happens to define 'fail' as a
> global variable, it may be an issue.
> 
> An option would be for library developers to systematically add a
> "local fail = nil" at the beginning of their modules (or "assert(not
> fail)")
> 
> 4. As Roberto explained:
>> "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."
> 
> So would you encourage developers to start using "return false, msg"
> in case of error instead of return nil, msg ?
> 
> TIA,
> 
> Phil
> 

This has been discussed before, with the usual back-and-forth about having a unique value that is falsy but is different from nil and false (which both have non-fail semantics in many cases). Roberto hasn’t been keen on such a thing (he shot me down pretty thoroughly lol), but I still think it’s a hole in the language.

—Tim