lua-users home
lua-l archive

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


On Sun, Sep 11, 2011 at 08:30:08PM +0200, Lorenzo Donati wrote:
> The meaning of a "bare" return statement, doesn't appear to be *clearly* 
> defined (or I couldn't find/understand it). Besides the effect 
> detectable by select (which is not part of the language), I cannot find 
> anything that guarantees that
> 
> return
> 
> and
> 
> return nil
> 
> have different semantics. 
> For example, Lua team could well change the 
> implementation between bugfix releases (say 5.1.4 and 5.1.5) and make 
> "return" behave as "return nil" and this won't go against anything 
> written in the manual. "select" will return 1 instead of 0, but this 
> again won't contradict the manual as it is".

The simple, clear idea in Lua is that when the calling routine tries to
retrieve a value not returned, you get `nil` instead of an error message.

I can't believe that the Lua team intended the programmer to write code 
which relies on a distinction between two or more of the cases:

 -  `end` (matching `function`) reached 
 -  `return` 
 -  `return nil` 
 -  `return a,b,c` when a,b,c all happen to be nil

Such code should not be expected to work, even though in practice it might.

In general, any artifact which can be exposed only by a library routine and 
is not explicitly documented, probably is not planned to be a feature 
exploitable by the programmer.

In this case, I'm happy with the manual not laboring the point.  Lua was not 
designed by Nicolas Bourbaki, thankfully, and its manual (though confessing 
to be dry in places) does not read like “Éléments de Mathématique”.

Dirk