develooper Front page | perl.perl5.porters | Postings from April 2018

Re: [perl #132142] Bleadperl v5.27.3-34-gf6107ca24b breaksMLEHMANN/AnyEvent-HTTP-2.23.tar.gz

Thread Previous | Thread Next
From:
Tom Molesworth via perl5-porters
Date:
April 20, 2018 05:37
Subject:
Re: [perl #132142] Bleadperl v5.27.3-34-gf6107ca24b breaksMLEHMANN/AnyEvent-HTTP-2.23.tar.gz
Message ID:
CAGXhHdk9=qhDBPYSM9jj6xuW26dqhYSX0XfM-k1FC=mW4O+osw@mail.gmail.com
On 20 April 2018 at 12:50, Andreas Koenig <
andreas.koenig.7os6VVqR@franz.ak.mind.de> wrote:

> It has been pointed out that the "internally optimized behaviour" of '@a
> = sort @a' was documented as a way to get an in-place sort. It was
> established behaviour for a long time. Given that it was both proudly
> announced and well established, I find the term "bug fix" for its
> removal problematic. This is a change in bahaviour. As such it may be a
> bug fix for one party and a breakage for the other. Fair discussion
> should try to balance the thinking and take this into account.


I believe the original release note from perl5100delta was:

>  In-place sorting
>    Sorting arrays in place ("@a = sort @a") is now optimized to avoid
making
>    a temporary copy of the array.
>
>    Likewise, "reverse sort ..." is now optimized to sort in reverse,
avoiding
>    the generation of a temporary intermediate list.

Since there was no corresponding documentation update to sort itself, and
no mention of how this would affect magic or weakrefs, I think it would be
reasonable to conclude that this is intended purely as a non-user-visible
optimisation? If the behaviour is intentional, then why (in 5.26) does it
only happen for sort, but not the reverse sort that was explicitly called
out in the same release note?


>
>   > 2) AnyEvent relied on this now-fixed buggy behaviour;
>
> The problematic terms continue.


The sort optimisation was added in 5.10. AnyEvent has test passes (and code
mention of) 5.8.0. If that's correct - I haven't looked at the relevant
code to confirm - then I think relying on in-place sort optimisation could
rightly be described as a bug?

When I mentioned the in-place sort issue to ilmari originally, I was under
the impression that it was a well-known bug that no one had ever got around
to fixing (similar to the case with plain reverse).

It's something I've run into a few times in the last few years, is more of
an annoyance than a genuine complaint, but does seem like an arbitrary
behavioural difference that should be discouraged rather than documented.
To me, it's very clearly a bug, and inconsistent: we have a fine example of
in-place modification in chomp(), I'd expect similar syntax for an in-place
sort or reverse feature.

cheers,

Tom

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About