develooper Front page | perl.perl5.porters | Postings from July 2009

Re: [PATCH] Remove implicit split to @_

Thread Previous | Thread Next
July 10, 2009 16:56
Re: [PATCH] Remove implicit split to @_
Message ID:
On Fri, Jul 10, 2009 at 02:42:01PM -0700, Chip Salzenberg wrote:
> [ SUMMARY: Only C<use 5.012> may disable split assignment to @_. ]
> [ METASUMMARY: Let's put this to bed.  Surely there are bigger fish to fry. ]
> Michael G Schwern <> writes:
> > Making it a compile-time error isn't compromise, its picking the lowest common
> > denominator.
> Compromise makes bad design.  Synthesis can make good design.  They're easy
> to mistake for each other, because both involve listening and adapting.
> Let's spell out the scenario of just changing split:
>   1. split in scalar context no longer assigns to @_.
>       the syntax of split does not change, only its semantics.  <--- vital point
>   2. people write code in Perl 5.12 that depends on the new semantics
>   3. it's syntactically valid Perl 5.10, 5.8, 5.6.1, etc.
>   4. when fed to those older Perls, the code compiles, but runs incorrectly
>   5. users feel they've been unfairly played
>   6. they're right
> Breaking upward _or_ downward compatibility *silently* without a damn good
> reason is impolite.  I like to be impolite only for good reason.  ("I don't
> believe in breaking small laws." -- The Rebel Set)

Well, it's not really silent. It has been given a deprecated warning
since at least 5.6.x. But I appreciate the reasoning.

> A story from the past: The ability to correctly read directories containing
> files named '0' is the reason Larry approved a change making
>    while ($x = <*>)
> to silently mean something new:
>    while (defined($x = <*>))
> As a practical matter this change was only good, even though it was a silent
> semantic change.  I bring up this story to show a silent semantic change is
> *not* always bad, and I get that.  But the reasons why the <*> change was
> safe do not apply here.
> So:
> If you really want scalar split to simply return a count and not assign to @_,
> then I'm OK with that... *if* it is only under C<use 5.012>.  Chairman Larry
> has been known to err, but I agree that "all is fair if you predeclare."
> When Perl 5.12 encounters scalar split and *not* under C<use 5.012>, it should
> either do 5.10 does, or die.  Those are the only two options that make sense
> if you're trying to make a usable tool.

Please. We have been through this. We really don't want programs to change
their behaviour in subtle ways if the 'use 5.12' line disappears.
That is, IMO, worse than the scenario you paint above.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About