TSConfig 'strict: false' leads to an error

[Gadicuz]

Bug Report

🔎 Search Terms

strict generic strictFunctionTypes

🕗 Version & Regression Information

I tried TS 4.9.4 and 4.8.4 on Playground.

⏯ Playground Link

Playground link with relevant code

I asked the question on Stackoverflow, but nobody answered,

💻 Code

import { of, tap, ignoreElements } from 'rxjs';
export class C {
  private bar: number[] = [];
  public foo() {
    return of([1]).pipe(
      tap((x) => (this.bar = x)),
      ignoreElements()
    );
  }
}

🙁 Actual behavior

The code is fine until you turn off 'strict' mode (to be precise 'strictFunctionTypes'). Uncheck 'strictFunctionTypes' and get errors in line this.bar = x:

Type 'unknown' is not assignable to type 'number[]'.
Type '{}' is missing the following properties from type 'number[]': length, pop, push, concat, and 26 more.

I discovered several ways to remove the errors in 'strict=false' mode:

• set explicitly type of arrow function argument x (x: number[]) => ...
• add another 'empty' tap() just before ignoreElements()
• remove ignoreElements() (removes error, alters behavior)

It seems pipe() signature resolves differently with strict mode on/off.
It's pipe<number[], never>(...) when strict=true
It's pipe<unknown, never>(...) when strict=false
I guess one of the reasons is ignoreElements(): OperatorFunction<unknown, never> signature with non-generic 'unknown'.

So I get error-free code with strict=true but it fails with strict=false.

🙂 Expected behavior

The strict flag enables a wide range of type checking behavior that results in stronger guarantees of program correctness.

Usually expect more errors in strict mode, but this error appears only if strict mode off.
Is this TS behavior intended? What is the recommended solution?

[RyanCavanaugh]

strictFunctionTypes doesn't mean that there are some errors that would normally appear and are simply suppressed, or not checked for. It's a fundamental change in how functions are assignable to each other. For any strictness flag like this, it's straightforward to construct (on purpose) a program that only errors in the non-strict mode, and is certainly possible to write such a program unintentionally, as appears to have happened here.

[fatcerberus]

For any strictness flag like this, it's straightforward to construct (on purpose) a program that only errors in the non-strict mode

Nonetheless this case is intriguing; given what strictFunctionTypes does, I wouldn’t expect it to make any assignments succeed that would have failed otherwise. If something is assignable under contravariance, it should also be assignable under bivariance, by definition

[github-actions]

This issue has been marked as 'Not a Defect' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[Fire-Dragon-DoL]

For any strictness flag like this, it's straightforward to construct (on purpose) a program that only errors in the non-strict mode

Nonetheless this case is intriguing; given what strictFunctionTypes does, I wouldn’t expect it to make any assignments succeed that would have failed otherwise. If something is assignable under contravariance, it should also be assignable under bivariance, by definition

Reporting this since I was caught off-guard. I expect strict: false to be a superset of strict: true, given how I interpret "lenient", while in reality strict true and strict false are really two very different modes with an intersection of same checks.