[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: no return value vs. nil return value(s)
- From: Dirk Laurie <dpl@...>
- Date: Sun, 11 Sep 2011 23:38:50 +0200
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