Re: [ANN] Lua 5.3.3 (rc1) now available

[Jonathan Goble <jcgoble3@...>]

On Thu, May 12, 2016 at 12:49 AM, Daurnimator <quae@daurnimator.com> wrote:
> On 12 May 2016 at 11:59, Jonathan Goble <jcgoble3@gmail.com> wrote:
>> On Fri, May 6, 2016 at 11:46 AM, Roberto Ierusalimschy
>> <roberto@inf.puc-rio.br> wrote:
>>> - new semantics for empty matches ("Python rule")
>>
>> After thinking about it for a few days, I'm going to argue that this
>> change flat-out does not belong in a bugfix release. It's not a bugfix
>> at all; it's a change in the behavior of a feature that, although it
>> is undocumented, is reasonably well-known enough that a
>> non-insignificant number of people and libraries may be reliant upon
>> the existing behavior, and is thus a backwards-incompatible change.
>>
>> The very fact that someone needed to start a thread a few days ago
>> asking how to programmatically distinguish between 5.3.2 and the
>> proposed 5.3.3 is indicative of the fact that this will break people's
>> code, violating the trust that people have regarding bugfix releases
>> being backwards compatible.
>>
>> Therefore, as a backwards-incompatible change, this feature should be
>> removed from the 5.3.3 release candidate and should be delayed until
>> 5.4 or 6.0 (whichever the next version ends up being).
>>
>> Thoughts on this?
>
> Previously the behaviour was undefined.
> Changes in undefined behaviour are allowed between implementations as
> well as between bugfix releases.

While technically true, I believe consideration must be given to the
fact that 1) the current behavior is well-known and relied upon by
some people, and 2) at least one person has asked how to distinguish
between 5.3.2 and 5.3.3, most likely because of this change causing
breakage.

I understand that it is technically undefined and thus technically can
be changed, but I think enough people are relying on this (e.g. I'm
guessing that many string-splitting functions are coded to work with
the existing behavior) that it's going to break too much code to be
acceptable for a bugfix release.

It's a case of "an exception to every rule"; in this case, we have
behavior that is undefined, yet well-known and relied upon, and common
sense tells me it will break too much code to include in a release
that's supposed to be backwards compatible, despite the rule that
technically allows it.