Skip to content
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

asserts that return type is null | Generic<T> is reported as null and lose the generic #49588

Closed
jdeniau opened this issue Jun 17, 2022 · 4 comments · Fixed by #49625
Closed
Labels
Duplicate An existing issue was already created

Comments

@jdeniau
Copy link

jdeniau commented Jun 17, 2022

Bug Report

🔎 Search Terms

  • asserts generic null
  • asserts array null

🕗 Version & Regression Information

  • This is the behavior in every version I tried (3.7 on the playground as asserts did appear in 3.7 IIRC), and I reviewed the FAQ for entries about null asserts

⏯ Playground Link

Playground link with relevant code

💻 Code

interface Generic<T> { value: T; }
type Ticket = {}
type TicketGeneric = null | Generic<string | Ticket>

function assertRelationIsNullOrGenericOfString(v: Generic<string | Ticket> | null): asserts v is Generic<string> | null {}

function testGeneric(ticketGeneric: TicketGeneric) {
  assertRelationIsNullOrGenericOfString(ticketGeneric)

  ticketGeneric;  // expected type is `null | Generic<string>` but gave `null`
}

🙁 Actual behavior

When an asserter return null or a Generic, it is reported as null.
It does this for every generic, even Array<string>. If the return type is not a generic, it does work fine (with null | string for exemple)

🙂 Expected behavior

It should be marked as null | Generic<string>

Thank you!

@MartinJohns
Copy link
Contributor

MartinJohns commented Jun 17, 2022

I believe this is a duplicate of #31156. Assertion functions are essentially like type guards. Same issue is reported in #37807, which was named a duplicate. Type assertions and type guards narrowing to union types have always been wonky.

@RyanCavanaugh
Copy link
Member

This one is actually working as intended, ish. See #35953 (comment)

@RyanCavanaugh RyanCavanaugh added the Duplicate An existing issue was already created label Jun 20, 2022
@RyanCavanaugh
Copy link
Member

This example doesn't have the subtype/assignability subtlety going on, but the general filter vs narrow behavior of UDTAs is intentional

@typescript-bot
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Duplicate An existing issue was already created
Projects
None yet
4 participants