Skip to content

Passing never type as a function parameter does not fail type check #56952

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
bluepnume opened this issue Jan 4, 2024 · 7 comments
Closed

Passing never type as a function parameter does not fail type check #56952

bluepnume opened this issue Jan 4, 2024 · 7 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@bluepnume
Copy link

πŸ”Ž Search Terms

never parameter argument

πŸ•— Version & Regression Information

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

⏯ Playground Link

https://www.typescriptlang.org/play?#code/FAMwrgdgxgLglgewgAhAhAKARgQwE7IBcyAzjHnBAOYCUyA3sMslEiQgDYCmAdBwlWz4aAbmABfYKEixEKKlxgA5LgDcueDHWIQ1Ghk2QwAFngQB3ZLssBRPGc0ADJQgAOXR6IlS0mBcr1NGlEgA

πŸ’» Code

function foo(bar : string) {
  console.log(bar);
}

function getNever() : never {
  throw new Error(`Nope`);
}

foo(getNever());

πŸ™ Actual behavior

No type errors

πŸ™‚ Expected behavior

Type error: can not pass type never to function foo

Additional information about the issue

No response

@RyanCavanaugh RyanCavanaugh added the Working as Intended The behavior described is the intended behavior; this is not a bug label Jan 4, 2024
@RyanCavanaugh
Copy link
Member

never is the empty set; the subtype of all types. By definition, it is assignable to anything.

@bluepnume
Copy link
Author

bluepnume commented Jan 4, 2024

OK, understood -- but is there a reason it doesn't work a bit more like unknown? Would there be any downside to preventing a never value to be passed around since that seems to indicate an error case, or at least probably not what the code author intended.

@RyanCavanaugh
Copy link
Member

I'm not sure what rule you're proposing. At best, you'd introduce many different inconsistencies where higher-order and zero-order forms disagreed about validity.

@bluepnume
Copy link
Author

bluepnume commented Jan 4, 2024

I'm arguing from a 'principle of least surprise' angle. If I try to pass a never value into a function, and that function doesn't explicitly accept never as a parameter type, there's like a 99% chance I'm doing something I shouldn't be, and a warning would help me fix that mistake.

My proposal is there would be some setting similar to noImplicitAny which makes never unusable. Once I have a never value, I would be unable to return it, pass it to any function, unless those functions explicitly have never types defined as inputs or outputs. Essentially how unknown behaves.

Is there a real world example where someone would actually want to be able to pass or return a never?

@RyanCavanaugh
Copy link
Member

Sure, you might have something like this

declare function myRoundingFunc(n: number): number;
declare function doSomething(value: number, ifEven: () => string, ifOdd: () => string, ifFractional: () => string): string;

// Input from somewhere
declare let n: number
n = myRoundingFunc(n);
const p = doSomething(n, () => "n is even", () => "n is odd", () => { throw new Error("This can't happen") });
console.log(p);

@MichalMarsalek
Copy link
Contributor

MichalMarsalek commented Jan 5, 2024

never is a subtype of all types while unknown is a supertype of all types. They are different by nature. I don't expect and don't want them to behave the same.

@typescript-bot
Copy link
Collaborator

This issue has been marked as "Working as Intended" and has seen no recent activity. It has been automatically closed for house-keeping purposes.

@typescript-bot typescript-bot closed this as not planned Won't fix, can't repro, duplicate, stale Jan 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

4 participants