> Isn’t it good programming practice to always check return values?
It is. It is also often one severely neglected in practice, even in environments much less forgiving than Lua.
Therefore, one is advised to practise making it impossible for an unsuspecting user to ignore an error silently.
I would suggest reading "A Philosophy of Software Design" by John Ousterhout. One of the suggestions he makes for C programs is to replace 'malloc' with a 'ckalloc' that checks for a NULL return and exits the program with an error message if you run out of memory. There's typically not much you can do when a C program runs out of memory.
The idea here is that you try not to saturate your code with error checks, which makes it harder to read. The idea is NOT that you ignore any errors.
Checking the return value only makes sense if the return value can actually indicate an error. In languages like C and Go that's the convention, so you absolutely should check return values. In languages like C++, Lua and others that use some kind of exception handling checking the return value may be pointless, depending on the interface you're using. 'require' comes out of the box 'throwing' an error string using 'lua_error', it does not return when it finds an error, and it does not support the "false, <errorstring>" convention. Other interfaces in Lua work differently (io.open for instance).
The suggestion was make 'require' return some kind of encoded error, which would then have to be checked. That's a change of behavior from the way 'require' normally works, which is not a good thing. Adding unexpected behavior to a well-known interface is a likely source of bugs. 'require' can also only return one value only, so you will have to come up with a non-standard way to encode an error return. I work with large code bases, and this kind of cleverness comes back to haunt you most of the time.
