if-statements allow multiple arguments and don't check for constant conditions after the first argument

[MajorMeerkatThe3rd]

🔎 Search Terms

"if statement", "constant condition"

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about common bugs

⏯ Playground Link

https://www.typescriptlang.org/play/?#code/MYewdgzgLgBBIFsCmBhAFk4BrAlmA5gGICuYwUO4MAvDABQAOAhgE5MICMAXHFC3vgA0MZmwQAmHtH4FhIBhXBMANgAVW7AMw0YfYkgCUNAHwwA3gCgY1mAHpbMACYhexAGZurNlkijEWYLos+gDcFgC+Fhb2MCoA7kwAnhAwbioQSMI+EMTKsCBucIioGNgCJGSKgfFJKTj4YCA+jhY4bnTwyOiYuAQV5JRgdABEouwcw8KjGhLDBsJpyhlGljYwEVExjkgMSGDbYPmB2bn5hZ0lPeWkA+Ct7RfdZX03VSNjnJMw02LiX4vLFZeawRIA

💻 Code

const someCheckingFunction = (param1: string, param2: string, optionalParam3 = true) => {
    // do stuff
    return true;
}

// always false, result of someCheckingFunction always ignored
if(someCheckingFunction("param1", "param2"), false) {
    
}

// dependent on result of someCheckingFunction
if(someCheckingFunction("param1", "param2", false)) {
    
}

🙁 Actual behavior

Due to a mistake in my bracket placement as seen in the example, I accidentally learned that multiple arguments in an if statement are possible.

Currently that means:

1. only the last argument is used for the if statement check
2. even for constant conditions there is not error visible

🙂 Expected behavior

What I would expect:

1. don't allow multiple arguments, this only happens because someone made an error
2. at least show an error if there is a constant condition

Additional information about the issue

No response

[MartinJohns]

That sounds more like a linter-job, and there is a rule already: https://eslint.org/docs/latest/rules/no-sequences

[MajorMeerkatThe3rd]

This rule seems to be very broad. For loops this behavior might make sense, I just don't see use cases for If-statements

[jcalz]

I'm not a TS team member, this is just my opinion:

This isn't "multiple arguments"; you're objecting to the JavaScript comma operator being used inside an if statement. I don't think TS complains about the comma operator unless it's sure the initial operands have no side effects.

I agree that it seems code-smelly to write if (x(), y) {} instead of x(); if (y) {}, but is it really never used in practice? This still feels like something a linter would be better equipped to handle, without introducing a breaking change for TS code in general. I think typescript-eslint lets you write custom rules.

[kirkwaiblinger]

(typescript-eslint team member) Agreed that this is a linter-y request. You don't even need a full custom rule for the described request; you can just use no-restricted-syntax with selector "IfStatement > SequenceExpression".

Our FAQ
ESLint's no-restricted-syntax rule docs
Demo of this configured in our playground

FWIW I'd just use no-sequences though and disable it where you really want them for some reason.

[Josh-Cena]

Do note however that TS already checks someCheckingFunction(...) && false and reports the if body as unreachable. I don't believe it's impossible for TS to realize that ..., false is also statically false, making the if body unreachable.

[Andarist]

I think i makes sense to handle some of the cases around comma expressions in TS, that said - an improvement for this (#60830) won't help this exact case because this exact case involves boolean literals and those are special-cased by the current syntactic truthy semantics:

if (true) {} // ok

We could handle those differently within comma expressions but @RyanCavanaugh would have to green light it first.

[MajorMeerkatThe3rd]

Thank you everyone for your input!

@kirkwaiblinger I'm now using the custom rule you provided, as within our code base there are instances of the comma-operator being used in other ways. My issue with it was specifically for if-statements. Thank you!

[RyanCavanaugh]

People do write code that is structurally similar to this on purpose somewhat often (not my style but it does happen).

The linked PR (which doesn't address OP's exact code) seems OK though