print scalar (1,2,3,4)[2];
[download]

Doesn't work, because you seem to want the scalar value of an array (it's size), but you're specifying a list.

I think that you are wrong on this one, notice:

print scalar (1,2,3,4)[2];    # syntax error at )[
print scalar((1,2,3,4)[2] );  # prints 3
print scalar+(1,2,3,4)[2];    # also prints 3
[download]

Your first answer applies to both. The scalar is just hogging the parens. It is also useless, as it is forcing a scalar context on a scalar.

Yep. You're right :)

---

Ordinary morality is for ordinary people. -- Aleister Crowley

Thanks phaylon.

I think the docu for + I wanted was in perlop: "Unary ``+'' has no effect whatsoever, even on strings. It is useful syntactically for separating a function name from a parenthesized expression that would otherwise be interpreted as the complete list of function arguments. (See examples above under Terms and List Operators (Leftward).)"

> perl -MO=Deparse -e 'print +(1,2,3,4)[4]'
print((1, 2, 3, 4)[4]);
-e syntax OK
[download]

    print (1,2,3,4)[1];
[download]

• It only warns for print, printf and sort - if you use a different function, and make the same mistake you might make with print, perl won't bother to warn you then.
• It only warns if there is exactly a single space between the function name and the opening paren. Using no space, two space, a tab or a newline doesn't trigger this warning. And you thought only Python had stupid whitespace rules.
• It doesn't trigger the warning if the closing parenthesis is followed (after optional white-space) by a semi-colon, a vertical bar, a closing paren, brace or bracket, an exclaimation mark, an equal sign, or one of the letters o, a, i, u, or w. But it does warn if it's followed by any other letter, an ampersand, or something else. We all know the significance of a, i, o, u and w, don't we?
• If finds the matching closing parenthesis without taking strings in consideration.

    print(1)           # No warning.
    print (1)          # Warning.
    print  (1)         # No warning.
    printf (1)         # Warning.
    sprintf (1)        # No warning.
    print
    (1)                # No warning.

    print (1) ||  die; # No warning.
    print (1) or  die; # No warning.
    print (1) xor die; # Warning.
    print (1) and die; # No warning.
    print (1) &&  die; # Warning.

    print (1) ==  1    # No warning.
    print (1) !=  1    # No warning.
    print (1) <=> 1    # Warning.

    print (1);  next   # No warning.
    print (1),  next   # Warning.
    print (1) | next   # No warning.
    print (1) & next   # Warning.

    print ("(")        # Warning.
    print (")")        # Warning.
    print ("1");       # No warning (trailing semi-colon).
    print (")");       # Warning (even with semi-colon).
    print ("1"); die;  # No warning.
    print ("("); die;  # Warning.
[download]

I heard this warning will play a major role in Dan Browns new novel.

I can certainly see why one set of warnings specificaly added to a function to address a specific set of common bugs/possible bugs, would lead you to stop advocating warnings.

The warning is intended to warn you that perl and you might have thought differently on how that statment was phrased, it is not intended to babysit you. If you don't like the current warnings then you could probably help out by supplying the code to make print warn on all those cases.


___________
Eric Hodges

If you don't like the current warnings then you could probably help out by supplying the code to make print warn on all those cases.

Believe me, I've tried to make the warnings more sane. I've send in patches. More than once. I've also tried to make remove the warning in its entirely. But if P5P wants to keep the warning as it, how am I supposed to do that?

BTW, I think perl should print the warning in none of those cases, as all cases I gave there's no error. Although it wouldn't be hard to create some cases where there is an error, but no warning is given.

The warning is intended to warn you that perl and you might have thought differently on how that statment was phrased, it is not intended to babysit you.

But you see, perl and I thought exactly the same on how the statement was "phrased", we both thought that "print (...)" was a function call. It's that perl thought I thought that perl thought differently. And that's where I think it goes too far. Such warnings are wrong too often, and warnings that are wrong too often are worse than not having warnings at all.

(1,2,3,4)[0] is an anonymous array containing 4 elements which is being subscripted to return the first element.

print (1,2,3,4) If it looks like a function it is a function. That's a function!

print scalar (1,2,3,4)[2] Rats - pocket reference fails me. I guess scalar binds more tightly to the array than does [] and you can't subscript a scalar.

print +(1,2,3,4)[3] Same as previous except that [] binds more tightly than + (again rats - [] not listed in precedence table!). + is a uniary operator.