implicit split to @_ considered counterintuitive

[p5pRT]

Migrated from rt.perl.org#1164 (status was 'resolved')

Searchable as RT1164$

[p5pRT]

From @vlbrown

When I run this code​:
  #!/usr/local/bin/perl -w

  $record = 'a b c d e f g';

  $x = split(/\s+/, $record);

  print $x, "\n";

(under Perl 5.005_02) I get​:

  Use of implicit split to @​_ is deprecated at foo.pl line 5.
  7

What implicit split to @​_?

Sayeth the Camel​: In scalar context, split returns the count of substrings
Which it does (7).

Sayeth perlfunc (on 5.005_03) under 'split'​:

"If not in list context, returns the number of fields found and splits
  into the C<@​_> array. (In list context, you can force the split into
  C<@​_> by using C<??> as the pattern delimiters, but it still returns
  the list value.) The use of implicit split to C<@​_> is deprecated,
  however, because it clobbers your subroutine arguments."

Note the "returns the number of fields found *and* splits into @​_" bit.

The use of implicit split to @​_ is deprecated? TAKE IT OUT. It should
not be there. This is scalar context, not sorta scalar and sorta list and
I'll just put the data somewhere. Don't tell me that "in scalar context split
returns a number" and then warn me about some implicit @​_. It should work or
not but not give a warning. That's dumb.

Perl Info

Site configuration information for perl 5.00502:

Configured by vlb at Tue Dec  1 13:04:02 PST 1998.

Summary of my perl5 (5.0 patchlevel 5 subversion 2) configuration:
   Platform:
     osname=solaris, osvers=2.6, archname=sun4-solaris
     uname='sunos jeeves 5.6 generic_105181-03 sun4u sparc 
sunw,ultra-enterprise '
     hint=recommended, useposix=true, d_sigaction=define
     usethreads=undef useperlio=undef d_sfio=undef
   Compiler:
     cc='gcc', optimize='-O', gccversion=2.8.1
     cppflags='-I/usr/local/include'
     ccflags ='-I/usr/local/include'
     stdchar='unsigned char', d_stdstdio=define, usevfork=false
     intsize=4, longsize=4, ptrsize=4, doublesize=8
     d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
     alignbytes=8, usemymalloc=y, prototype=define
   Linker and Libraries:
     ld='gcc', ldflags =' -L/usr/local/lib'
     libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib
     libs=-lsocket -lnsl -ldb -ldl -lm -lc -lcrypt
     libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
   Dynamic Linking:
     dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
     cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib'

Locally applied patches:
 


@INC for perl 5.00502:
     /usr/local/lib/perl5/5.00502/sun4-solaris
     /usr/local/lib/perl5/5.00502
     /usr/local/lib/perl5/site_perl/5.005/sun4-solaris
     /usr/local/lib/perl5/site_perl/5.005
     .


Environment for perl 5.00502:
     HOME=/export/home/vlb
     LANG (unset)
     LD_LIBRARY_PATH=/usr/usr2/oracle/product/8.0.5/lib
     LOGDIR (unset)
  
PATH=/usr/local/sbin:/export/home/vlb/bin:/export/home/vlb/nib:/usr/lo 
cal/bin:/opt/SUNWspro/bin:/usr/ccs/bin:/usr/ucb:/usr/bin:/bin:/etc:/sb 
in:/usr/sbin:/usr/openwin/bin:/usr/usr2/oracle/product/8.0.5/bin:/usr/ 
dt/bin:/usr/local/genome/bin:/usr/games:.
     PERL_BADLANG (unset)
     SHELL=/usr/bin/tcsh
-----
  //=\   Vicki Brown <vlb@deltagen.com>
  \=//    Journeyman Sourcerer: Scripts & Philtres
   //=\
   \=//     Scientific Programming <> Perl, Unix, Mac
    //=\     A little Web gardening on the weekends
    \=//
     //=\      Deltagen, Inc; 1031 Bing St, San Carlos, CA 94070

[p5pRT]

From [Unknown Contact. See original ticket]

Features must not be removed from Perl without first going through a
deprecation cycle. This is not dumb, but rather necessary to provide fair
warning to programmers who have been using the feature.

What do you think of making things scheduled like this become
mandatory warnings before they completely stop working?

I'll support giving the axe to the implicit split if we
can make // always repeat the last match irrespective of
success, the way it does in (fixed versions of) vi. :-)

--tom

[p5pRT]

From [Unknown Contact. See original ticket]

In message <v04210108b3cd04005beb@​[207.135.77.148]>,
  Vicki Brown writes​:
: What implicit split to @​_?

You ask this and then go on to quote the docs. I find that puzzling.

: Note the "returns the number of fields found *and* splits into @​_" bit.

This is to support old code. Did you use version 4 or earlier?

: The use of implicit split to @​_ is deprecated? TAKE IT OUT.

We don't like to snatch the rug from beneath people without bulletproof
reasons. Think of going through a deprecation cycle as a manner of
politeness a civility.

: It should not be there.

It's deprecated. That means it's likely to be on the way out. Larry
told Chip that anything that's currently deprecated is fair game for
the chopping block in Topaz.

: This is scalar context, not sorta scalar and sorta list and
: I'll just put the data somewhere.

It's documented behavior that has a long history.

: Don't tell me that "in scalar context split returns a number" and then
: warn me about some implicit @​_.

Don't read the docs and you won't have to learn anything you don't want
to.

: It should work or not but not give a warning.

Try assigning to $* when you get a chance. You can disable warnings,
you know.

: That's dumb.

You misspelled "I'm".

Greg

[p5pRT]

From @tamias

On Tue, Aug 03, 1999 at 01​:39​:52PM -0700, Vicki Brown wrote​:

The use of implicit split to @​_ is deprecated? TAKE IT OUT. It should
not be there. This is scalar context, not sorta scalar and sorta list and
I'll just put the data somewhere. Don't tell me that "in scalar context split
returns a number" and then warn me about some implicit @​_. It should work or
not but not give a warning. That's dumb.

Features must not be removed from Perl without first going through a
deprecation cycle. This is not dumb, but rather necessary to provide fair
warning to programmers who have been using the feature.

Ronald

[p5pRT]

From [Unknown Contact. See original ticket]

Tom Christiansen writes​:

What do you think of making things scheduled like this become
mandatory warnings before they completely stop working?

Mandatory warnings suck.

Not as bad as breaking something.

--tom

[p5pRT]

From [Unknown Contact. See original ticket]

Tom Christiansen writes​:

What do you think of making things scheduled like this become
mandatory warnings before they completely stop working?

Mandatory warnings suck. Have a deprecated warning set for the
lexical warnings, so you can say use warnings 'deprecation'; or use
warnings 'of imminent breakage'; or something like that.

Nat

[p5pRT]

From @vlbrown

At 16​:39 -0600 8/3/99, Nathan Torkington wrote​:

Tom Christiansen writes​:

What do you think of making things scheduled like this become
mandatory warnings before they completely stop working?

Mandatory warnings suck. Have a deprecated warning set for the
lexical warnings, so you can say use warnings 'deprecation'; or use
warnings 'of imminent breakage'; or something like that.

or use warnings 'of extreme stupidity checking'
I could be very deliriously delighted with this :-)

As it stands right now, my choices are either to turn off -w (no :)
or to stop using split in scalar context (sigh).

By forcing me to get this warning,the simple use of split in scalar
context has effectively been deprecated along with the implicit split
to @​_ (which happens to be undocumented, as near as I can tell, in
the 3/98 printing of The Camel, 2nd ed). That's sad, to say the
least. It's annoying to say more. I understand... I do not have to
like it.

I recognize the desire not to break code... although sometimes one
needs to bite the bullet. I also look forward with rapt anticipation
to the day when -w is a lot less overweening.
-- --
  |\ _,,,---,,_ Vicki Brown <vlb@​cfcl.com>
  ZZZzz /,`.-'`' -. ;-;;,_ Journeyman Sourceror​: Scripts & Philtres
  |,4- ) )-,_. ,\ ( `'-' P.O. Box 1269 San Bruno CA 94066
  '---''(_/--' `-'\_) http​://www.cfcl.com/~vlb http​://www.macperl.com

[p5pRT]

From [Unknown Contact. See original ticket]

Tom Christiansen writes​:

Mandatory warnings suck.
Not as bad as breaking something.

These big breakages will only happen at a major version change, Larry
has said as much. Inserting a mandatory warning into 5 for something
that will break in 6 is silly. You should give people the option to
check whether their code will break under 6, by enabling a lexical
warning.

Nat

[p5pRT]

From [Unknown Contact. See original ticket]

These big breakages will only happen at a major version change, Larry
has said as much. Inserting a mandatory warning into 5 for something
that will break in 6 is silly. You should give people the option to
check whether their code will break under 6, by enabling a lexical
warning.

When Larry effectively changed the precedences in perl4 to perl5, this
caused some programs to *break*. It was not considered acceptable
that they should be silently doing the wrong thing. So we have cases
of mandatory warnings​:

% perl -ce 'open FILE || die'
Precedence problem​: open FILE should be open(FILE) at -e line 1.

This is just one step away from complete compilation failure​:

% perl -ce 'print "fred@​home"'
In string, @​home now must be written as \@​home at -e line 1, near "fred@​home"
-e had compilation errors.

I believe that anything that's getting a -w deprecated warning now in
perl5 should in perl6 incur a mandatory warning if its functionality
changes. As you see, there's ample precedent for that, and that there
exist circumstances in which mandatory warnings are justifiable.

--tom

[p5pRT]

From [Unknown Contact. See original ticket]

As it stands right now, my choices are either to turn off -w (no :)
or to stop using split in scalar context (sigh).

Or to be more imaginative​:

  $count = do { my @​tmp = split /​:/, $line };

--tom

[p5pRT]

From [Unknown Contact. See original ticket]

Tom Christiansen[SMTP​:tchrist@​jhereg.perl.com] wrote​:

As it stands right now, my choices are either to turn off -w (no :)
or to stop using split in scalar context (sigh).

Or to be more imaginative​:

$count = do \{ my @​tmp = split /​:/\, $line \};

...or an old standby​:

  $count=@​{[split /​:/,$line]};

TMTOWTDI,

Jim Williams

[p5pRT]

From @perhunter

"WJP" == Williams, James P <James.P.Williams@​USAHQ.UnitedSpaceAlliance.com> writes​:

  WJP> Tom Christiansen[SMTP​:tchrist@​jhereg.perl.com] wrote​:
  >> >As it stands right now, my choices are either to turn off -w (no :)
  >> >or to stop using split in scalar context (sigh).
  >>
  >> Or to be more imaginative​:
  >>
  >> $count = do { my @​tmp = split /​:/, $line };

  WJP> ...or an old standby​:

  WJP> $count=@​{[split /​:/,$line]};

since it is only a single char, why not just use tr/// to count the :
and then bump it by 1 for the field count. gotta be much faster than any
of the split variations.

uri

--
Uri Guttman ----------------- SYStems ARCHitecture and Software Engineering
uri@​sysarch.com --------------------------- Perl, Internet, UNIX Consulting
Have Perl, Will Travel ----------------------------- http​://www.sysarch.com
The Best Search Engine on the Net ------------- http​://www.northernlight.com
"F**king Windows 98", said the general in South Park before shooting Bill.

[p5pRT]

From [Unknown Contact. See original ticket]

On Tue, Aug 03, 1999 at 08​:08​:56PM -0500, "Williams, James P" wrote​:

Tom Christiansen[SMTP​:tchrist@​jhereg.perl.com] wrote​:

As it stands right now, my choices are either to turn off -w (no :)
or to stop using split in scalar context (sigh).

Or to be more imaginative​:

$count = do \{ my @​tmp = split /​:/\, $line \};

...or an old standby​:
$count=@​{[split /​:/,$line]};

  $count = length$line&&1+$line=~tr/​://;

:-)

mark

P.S. Errr ... it's late at night ... and the evil perl gremlin got to me ...

  $count = length($line) && 1 + $line =~ tr/​://;

  It only works if the separator is one literal character, and the
  behaviour you want is "split(pat, str, -1)". But it's faster... :-)

  use Benchmark;

  $line = "1​:field2​:this_is_field3​:4​:field5​:this_is_field6";

  timethese(500000, {
  'TomC' => sub { $count = do { my @​tmp = split /​:/, $line } },
  'JamesW' => sub { $count = @​{[split /​:/, $line]} },
  'MarkM' => sub { $count = length($line) && 1 + $line =~ tr/​:// },
  } );

  Output​:

  Benchmark​: timing 500000 iterations of JamesW, MarkM, TomC...
  JamesW​: 32 wallclock secs (33.17 usr + 0.00 sys = 33.17 CPU)
  MarkM​: 10 wallclock secs (10.73 usr + 0.00 sys = 10.73 CPU)
  TomC​: 32 wallclock secs (30.96 usr + 0.00 sys = 30.96 CPU)

  I don't even know why I'm still at work... sheesh...

  But I did finally come up with a use for short circuiting &&... :-)

--
markm@​nortelnetworks.com/mark@​mielke.cc/markm@​ncf.ca __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | CUE Development (4Y21)
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | Nortel Networks
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
  and in the darkness bind them...

  http​://mark.mielke.cc/

[p5pRT]

From @pmqs

From​: Nathan Torkington [mailto​:gnat@​frii.com]

Tom Christiansen writes​:

What do you think of making things scheduled like this become
mandatory warnings before they completely stop working?

Mandatory warnings suck. Have a deprecated warning set for the
lexical warnings, so you can say use warnings 'deprecation'; or use
warnings 'of imminent breakage'; or something like that.

Err, there already is a "deprecated" lexical warning category.

Paul

[p5pRT]

From [Unknown Contact. See original ticket]

On Tue, 03 Aug 1999 at 13​:39​:52 -0700, Vicki Brown wrote​:

$x = split\(/\\s\+/\, $record\);
Use of implicit split to @​\_ is deprecated at foo\.pl line 5\.

Sayeth the Camel​: In scalar context, split returns the count of substrings
Which it does (7).

The Camel evidently tells not the full truth. Ask for your money back.
Well, some of it.

The use of implicit split to @​_ is deprecated? TAKE IT OUT. It should
not be there. This is scalar context, not sorta scalar and sorta list and
I'll just put the data somewhere. Don't tell me that "in scalar context split
returns a number" and then warn me about some implicit @​_. It should work or
not but not give a warning. That's dumb.

Not really dumb; it's history. Perl runs many scripts (it runs,
correctly, one of mine which has an SCCS revision date of 30 Nov 1989).
Some of them have implicit splits in them, and their owners need to be
told without the script breaking. It's normal for a feature to spend
its time in purgatory before being cast out into the outer darkness. Be
patient.

There isn't, I grant you, any handy way of counting RE matches in a
string [unless you use (?{}), of course], which your requested
non-splitting split would do, sort of. There should be a Better Way.

Ian
--
  I am confident this explanation will dispell any feelings
  of certainty that may have been troubling you.
  - BWHOLMES@​SJSUVM1.sjsu.edu (Cabbage) in <9601221753.AA27669@​spock>