[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Documentation for multiple assignment fails to mention order
- From: Coda Highland <chighland@...>
- Date: Mon, 25 Jul 2016 11:07:25 -0700
On Mon, Jul 25, 2016 at 10:24 AM, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
> Check your words. "unspecified behavior" (what the C standard says) is
> different from "undefined behavior" (what you asked about). Lhf is
> correct in saying that the behavior is not undefined, even though it is
> unspecified.
>
> About the manual itself: there are infinite things that Lua does not do
> but the manual fails to mention. So, if the manual does not define in
> what order __newindex metamethods in multiple assignments are called,
> it is safe to assume that the order is unspecified, even if the manual
> does not say that.
Respectfully, I disagree with this argument. While it is true that
unspecified behavior is not the same as undefined behavior, undefined
behavior is tautologically defined as "behavior that is not defined".
The documentation for the language is the source of all definitions.
Any behavior that is not documented is therefore, by definition,
undefined behavior.
It can be concluded syllogistically that the execution order of
multiple assignments in Lua is undefined.
All undefined behaviors are unspecified, because in the case of Lua
the core language documentation is also the language specification.
The distinction is that when something is defined to be unspecified,
the scope of permissible behaviors is in the process implicitly
defined. (In this example, defining the order of assignments as being
unspecified would mean that any ordering would be permissible, but
that terminating the process -- not being an ordering of the
assignments -- would not be expected.)
That said, I don't disagree with your conclusion: The manual doesn't
say anything about it, so the order is undefined, and that's a
completely acceptable state of being.
/s/ Adam