Em qui, 3 de out de 2019 às 14:19, Phil Leblanc <philanc@gmail.com> escreveu:
> I am surprised with the 'fail' notation thing. Was I living under a
> rock and did I miss some discussion here? :-)
I feel the same...
> Also "The recommendation is to test the success of these functions
> with (not status), instead of (status == nil)", so obviously 'fail' is
> going to be a third false value.
By using (not status) we would not differ a false return value from a fail.
> Could you please elaborate on your plans? Is it to use 'fail' for
> error and somehow allow 'nil' in tables?
Good!
> As I said above, returning (nil, error_message) is a well established
> idiom, used by probably all Lua libraries, C extension modules and
> programs. Do you expect library developers to update their code to use
> 'fail', or keep dual version using 'fail' for new Lua and keep using
> nil for old pre-5.4 Lua? Or define in their libraries a global
> 'fail=nil' which would defeat your (future) purpose?
Be careful not to define 'fail = true' ! Maybe we shoud define a local instead!
> I am puzzled.
Me too. But, as always, Roberto will explain everything ;-)
Regards,
Tomás
My understanding from a very quick glance at the manual (and without looking at the code) earlier today is that fail is not an actual defined value in itself, but rather a documentation notation indicating an arbitrary value whose only guarantee is that it tests false in a boolean context. Currently the only such values are nil and false itself, and functions that return fail on failure currently return nil, but they are opening the door to change that to a different falsy value (either false itself or a new falsy value) arbitrarily while saying that you can't rely on it to be a specific value, only to satisfy the condition "not value".
As for useful return values, the idiom in Lua has long been that functions which signal failure via return values return a falsy value and an error message on failure and "true" followed by the actual useful return values on success. As far as I could tell, that hasn't changed at all, so the first return value from such functions is merely a boolean indicator of success or failure and the useful data (on success) begins with the second return value.
Again, this is from a quick glance through the reference manual diffs, and without looking at the code, so it's very possible I missed something major, but it's the impression I got from the reference manual changes.
