The "?" operator would be forbidden before the "!" operator

[Chklang]

🔎 Search Terms

typescript ? operator with !

🕗 Version & Regression Information

Versions tested : 5.9.3 and 5.6.3

⏯ Playground Link

No response

💻 Code

interface A {
  b?: string;
}
function tt(v?: A) {
  const str: string = v?.b!;
  return str;
}
console.log("Value : ", tt());

🙁 Actual behavior

The result is : "Value : undefined"

🙂 Expected behavior

Compilator must refuse to combine ? before an !

v?.b! must to be refuse by typescript compilator. We must do "v!.b!" to have the good type.

Additional information about the issue

No response

[MartinJohns]

That wouldn't make sense. The ?. operator has clear runtime semantics that matter.

v?.b! says treat the entire expression as non-nullable, makes sense if e.g. b could be nullable. It will not throw an error when v is undefined.
v!.b! however will throw an error if v is undefined.

[nmain]

If that's how you feel, there's a lint rule for this: https://typescript-eslint.io/rules/no-non-null-asserted-optional-chain

[Chklang]

Thanks for the linter, it's great!

But i don't understand why is not in typescript compilator. I know that "?" is for runtime semantic. But typescript is here to check types at compilation, and says that "v?.b!" cannot be undefined/null is problematic. The "!" not says "ignore the null possibility" but says "i know that here it's not null because by algorithm it's cannot be null". "v?.b!" says "maybe it can be null", there is no compilator check, it's more "js-approch" than "ts-approch".

[MartinJohns]

The "!" not says "ignore the null possibility" but says "i know that here it's not null because by algorithm it's cannot be null".

The ! operator very much says "ignore the nullable possibility". The very purpose of the operator is to reduce type checks.

Sometimes you need to treat a type as another (e.g. an API only accepting string, but you know it can handle undefined as well).

[RyanCavanaugh]

Every downcast throws away some values that are possibly in the operand's domain. We also get the converse request which is to disallow ! when undefined/null isn't in the operand, which would put us in the position where ! is never allowed -- well, why does it even exist then?

One reason you might end up doing a?.b! is, for example

incorrectlyDeclaredFunc(a?.b!);

where the function claims it can't handle undefined but it actually can.