On Thu, Jun 10, 2021 at 7:16 PM Pierpaolo Bernardi <olopierpa@gmail.com> wrote:
> This may be true for the implementation that you checked.
>
> What the language guarantees is: nothing.
This is illogical, because Lua is a versioned language, and each Lua
version is defined by the corresponding open-source implementation and
manual, modulo bugs.
For the record, the description I gave is based entirely on the manual
for Lua 5.4 (but either one could still have bugs).
It may also be correct for other versions of Lua, though.
That is not how open-source software works. You cannot look at how an undocumented behavior works and automatically assume that it is guaranteed to behave that way. Software is defined by its documentation, and ONLY by its documentation. There are perfectly valid reasons, frequently used, for a particular behavior to be undocumented or decoumented as undefined.
The most common reason is to avoid making unnecessary guarantees that place future constraints on internal details that the developers may wish to optimize in the future. In the case of next(), if it is documented to have the specific, precise behavior it currently displays, that becomes a guarantee of the language and future reworks and optimizations of the internals are now constrained by the need to maintain that guarantee, which could prevent an optimization that would only be possible by breaking that promise.
On the other hand, explicitly saying "this is undefined" (or in some cases, just omitting something from the documentation entirely) means that there is no language-level guarantee of this specific behavior, which in turn means that the developers are free to optimize the internal structure and implement new features without having to worry about whether the existing undefined behavior is maintained. Such optimizations with incompatible behavior in an undefined case could occur even in a bugfix release, when you do not expect backward-incompatible changes.
That is why it is perfectly valid to document something as undefined even when the behavior is consistent in a given implementation and version. That is also why you should never rely on undocumented or undefined behavior even when the behavior is consistent in a given implementation and version.
