Just because a language knows what you mean to do and can give a specific error messagr doesn't mean that, in general, and specifically, the developers want to commit to supporting && as valid syntax forever.

Perhaps the language creators have plans for future syntax that would not allow what you want. Even if for now the language evidently knows what you mean from the error message.

In this specific case, the developers of fish apparently decided && was good to add.

That reminds me of the very specific nag messages I get from Python 3 when I don't write parens around parameters for print... do what I want already.

What does someone want if they write "bar = print foo,"? Is it the same if "print" isn't the built-in function?

Operator precedence isn't really a new concept, and Python relies on it in plenty other situations:

    bar = 1 + 1

I do believe Python made the right call, actually: print needed to be unified with functions, and dropping the requirement for parenthesis for function calls would have introduced so much incompatibility as to make the Python 2 -> 3 transition far more difficult.

But ignoring the legacy issue, there is a better way to do function calls, and it is ruby.

What does operator precedence have to do with this? Ending a parameter list with a comma changes the output of the print keyword but not a function. Assignment statements can contain function calls but not the print keyword.

C style function calls are common, explicit, and consistent. Python adds the best combination of positional, variadic, and named parameters of any language I know. ML style has less punctuation and simpler grouping rules. Ruby has the weaknesses of both.

Haskell/ml/caml do it better than Ruby.

    f 1 2
    (f 1 2).thing

Here the parentheses are nothing special, they just hint precedence.

As opposed to

    f 1, 2
    f(1, 2).thing

Awkward special-case commas and parentheses.

Didn't Ruby borrow it from Perl?

And lisp, just less parentheses

That usage doesn't get the weirdly specific error message though. It's only the Python2-ish statement that gets one.

What does someone want "print foo" to do if "print" is a different function?

What does someone want "print (1, 2)" to do if "print" is the built-in function? It prints a tuple in Python 2 and ints in Python 3.

I get that. So the Python 3 interpreter has to assume that when I say "print (1, 2)", I actually mean, print these two individual arguments.

If I say "print 'foo'" though, it recommends "print ('foo')", but doesn't go all the way to assume I actually meant that. There's a piece of code handling that special case that stops short of actually interpreting what I apparently mean.

The frustration around that was the original point.

In Python 3 there was an explicit decision not to support print as a statement, and rather as a function call.

You missed the point... that decision should have been made.