in reply to More intelligent warning?

I think the warning is still appropriate in your cases, because split modifies @_ in both cases, which I consider unfortunate :-):

>perl -le "$_='abc';@_=qw(1 2 3);$n=split//;print for @_"
a
b
c

[download]

Maybe the warning should be split used in scalar context in your case, and remain as is for void context, or maybe split in non-list-context should be deprecated due to its side-effect.

Replies are listed 'Best First'.
Re^2: More intelligent warning?
by BrowserUk (Patriarch) on Feb 05, 2010 at 14:57 UTC

    Hm That's a real "WTF were they thinking" moment :)

    Most of Perl's oddities you can squint your eyes a bit and see how and why they came about. And often, how useful they can be.

    But "I know you asked me for the count of tokens, but by the way, I've also stuck those tokens into @_ (silently overwriting your sub args!) just in case that's useful."? Nope! I can not see any rational for that.

    How long does that deprecation cycle have to last before the Guardians of the Lazy will let this be changed? :)

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

      I guess it's too late for 5.12, but for 5.14, I consider it fair game. And yes, I really dislike this side effect, even though it might come in very handy while golfing or for obfuscation...

[reply]
      Hm That's a real "WTF were they thinking" moment :)

      Most of Perl's oddities you can squint your eyes a bit and see how and why they came about. And often, how useful they can be.

      Indeed!

      ... wouldn't it be nice to have a no oddity pragma to deactivate all these rarely needed special features?

      Cheers Rolf

[reply]
[d/l]

        Hm. Interesting idea. What else would you include?

        How about disabling the use of @ARGV as the implicit target of push, pop, shift, unshift (other?) outside of a sub?

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
      But "I know you asked me for the count of tokens, but by the way, I've also stuck those tokens into @_ (silently overwriting your sub args!) just in case that's useful."? Nope! I can not see any rational for that.
      You're assuming split was written to easily count the number of tokens. It wasn't. It was written to split a string. Which it does. Even in void and scalar context. The fact it returns the number of tokens in scalar context is the additional feature, not its reason for existence.

      I guess the reasoning was "Hmmm, we have a function that splits a string into other strings. What can we do if there are users who call this in non-list context?" Not throwing away the result and putting in in the default list topicalizer doesn't seem that far fetched to me.

[reply]
        You're assuming split was written to easily count the number of tokens.

        Um. Nope. I made no such assumption. Thats purely your assumption.

        I agree part way. I can see the thought train that leads to some of it. I've written this function that splits strings. It can be called in 3 contexts. What is the logical thing to do in those contexts?

        1. List context: return the list of bits.
        2. Scalar context: Return how many bits.
        3. Void context: He's asked us to split, but wants nothing back. I guess we could stick the bits in @_ and let him access them there.

        But, I fail to see a good (nor even a bad) use case for returning the count AND sticking the bits in @_.

        Maybe there's one, but I just don't see it. If it stuck them in @F per -a, maybe.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
      Nope! I can not see any rational for that.

      Hmm, well. $_ is the default "this", so @_ is the default "these". If split is called implicitly on $_, it seems somewhat logical to me to implicitly split into @_.

      Bu then, the following arguably should not implicitly split into @_ : 

      perl -wle '$n="";$f="abc";$n=split//,$f;print for @_'

      [download]

      To defeat that behavior we have to use the "operator" with the disputed name... 

      perl -wle '$n=""; $f="abc"; $n=()=split//,$f; print for @_'

      [download]

      update:

      That looks like coming from looong ago. Consider: 

      while(<>) {
    $n = split;
    warn "processing $n tokens\n";
    &process; # implicitly takes @_
}

      [download]
      So... another reminiscence of perl4. perl4!
[reply]
[d/l]
[select]

        I don't have a problem with the implicit split to @_, when called in a void context. It wouldn't do anything useful at all otherwise.

        And the number of items produced is then readily availble as scalar @_: 

        while(<>) {
    split;
    warn "processing " . @_ . " tokens\n";
    &process; # implicitly takes @_
}

        [download]

        Having split in a scalar context just return the count also makes sense. (To me at least.)

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom