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

Re: [PATCH] Remove implicit split to @_

Thread Previous | Thread Next
Michael G Schwern
July 9, 2009 20:49
Re: [PATCH] Remove implicit split to @_
Message ID:
Yitzchak Scott-Thoennes wrote:
> I was trying to give the IMO underappreciated y/// some love.  It's hard
> to say for sure what I'd really do, since I find it hard to imagine
> counting fields without actually wanting the fields:
> @fields = split ...;
> $field_count = @fields;
> but if it actually came up in practice, I might just:
> $field_count = () = split ...;

Which doesn't work.

$ perl -wle '$count = () = split / /, "foo bar baz";  print $count'

Again, this underscores the point that there really needs to be a not clever
way to do this.

I'd like to point out that this already works:

    my $count = split ...;

Its only the split to @_ side-effect that's really in question, or was really
deprecated.  The docs say the whole of split in scalar context is deprecated.
The warning, which is what people pay attention to, only refers to splitting
to @_.

> I'm not completely satisfied that "fixing" scalar context is the right
> thing to do; just like with sort, where there are several "right" scalar
> context behaviors.

sort() is a different story.  It always (and I'm sure someone can do some
trick to make this not true) returns the same number of elements as you put
in.  So using it in scalar context is a no-op.  Thus making sort in scalar
context do something else, like the first element, has some merit.

split() returns a variable number of elements, so its at least interesting to
get the count.

I'd like to point out that we still don't have a working sort in scalar
context.  We all agree that the current behavior is wrong but never agreed on
what it should be.  I'd like this not to wind up the same way.

> With my C hat on, I'd expect it to return the first field, like strtok.
> Without it, I'd be as inclined to expect the last field as to expect
> a count.

While that might all be interesting, and we can come up with interesting
things all day, like maybe it should return an array reference, it violates
the general Perl rule of "arrays return the count in scalar context" (yes, I
know perlfunc denies the existence of that rule) that similar core Perl
functions follow.  Arrays, map and grep for example.

In short, core Perl functions don't work that way.

We have decent ways to do this already:

    my($first) = $line =~ m{^ ([^\t]*) }x;
    my($last)  = $line =~ m{ ([^\t]*) $}x;

Which doesn't involve arguing which one scalar context should do.

Perhaps the trainers can provide some insight?

I'd like to point out this still leaves us open to what things like split and
map and grep and sort should do in scalar context, return a lazily evaluated
iterator.  Numerically overload it to return the count for compatibility.
Then you've got $iter->first and $iter->last and $iter->count and $iter->next
and all this arguing over what it should do is gone because it can do it all.

But please don't let that hold up this simple patch.

52. Not allowed to yell "Take that Cobra" at the rifle range.
    -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army

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