GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Empty intersections as function return types are not treated as `never` · Issue #47833 · microsoft/TypeScript

Empty intersections as function return types are not treated as never #47833

New issue
Copy link
New issue
Copy link
Open
Open
Empty intersections as function return types are not treated as never#47833
Copy link
Labels
Experience EnhancementNoncontroversial enhancementsNoncontroversial enhancementsSuggestionAn idea for TypeScriptAn idea for TypeScript
Milestone
Backlog

Description

@lowr
LowR (lowr)
opened on Feb 10, 2022
Issue body actions

Bug Report

🔎 Search Terms

empty intersections, never, return type

🕗 Version & Regression Information

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

⏯ Playground Link

strictNullChecks: false

strictNullChecks: true

💻 Code

type A = { p: "A" };
type B = { p: "B" };

function f1(): never {
  return;
}

function f2(): A & B {
  return;
}

function g1(): never {}

function g2(): A & B {}

🙁 Actual behavior

f1: Type 'undefined' is not assignable to type 'never'. (expected)
f2 w/ strictNullChecks: false: no error emitted
f2 w/ strictNullChecks: true: Type 'undefined' is not assignable to type 'never'. The intersection 'A & B' was reduced to 'never' because property 'p' has conflicting types in some constituents. (expected)

g1: A function returning 'never' cannot have a reachable end point. (expected)
g2: A function whose declared type is neither 'void' nor 'any' must return a value.

🙂 Expected behavior

f2 and g2 should generate the same errors as f1 and g1 respectively other than elaboration on empty intersection types.

Note: I was suggested to separate fix from #47751 and I'm ready to submit another PR if this is really a bug.

Reacted by Torsten Severing and Sean Blonien

Activity

  1. RyanCavanaugh commented on Feb 10, 2022

    @RyanCavanaugh
    Ryan Cavanaugh (RyanCavanaugh)
    on Feb 10, 2022
    Member
    More actions

    I don't really see a defect per se here, g2 still has an error. We don't give it the special-cased error message about never but the error is effectively telling you the same thing, and why would someone write code like this on purpose?

  2. lowr commented on Feb 10, 2022

    @lowr
    LowR (lowr)
    on Feb 10, 2022
    ContributorAuthor
    More actions

    Is it really telling you the same thing? If I see the current error message on g2 I'd try to return something until I notice the return type is never. Worse, if I try adding return; at the end of the function just to try to please the compiler (which I shouldn't, of course!), g2 becomes f2, which under strictNullChecks: false wouldn't emit any error.

    I understand that the above code is contrived, but this may emerge in larger code bases with generics, possibly by unintentionally declaring a function's return type as an empty intersection. Quote from #36696 (comment):

    It is obviously uncommon to have type annotations that explicitly intersect disjoint types, as in the examples above. The root cause of empty intersections is typically instantiations of generic types that intersect type parameters.

    Seeing no one else has ever reported this as a bug, I can argue that no one would actually confront something like this, but I'd say "fixing" this would make the compiler a bit more friendly to the users.

  3. RyanCavanaugh commented on Feb 10, 2022

    @RyanCavanaugh
    Ryan Cavanaugh (RyanCavanaugh)
    on Feb 10, 2022
    Member
    More actions

    It's correct to not error under snc: false because { p: undefined } is a legal return value

  4. Ryan Cavanaugh (RyanCavanaugh)
    added
    Experience EnhancementNoncontroversial enhancementsNoncontroversial enhancements
    SuggestionAn idea for TypeScriptAn idea for TypeScript
    on Feb 10, 2022
  5. RyanCavanaugh commented on Feb 10, 2022

    @RyanCavanaugh
    Ryan Cavanaugh (RyanCavanaugh)
    on Feb 10, 2022
    Member
    More actions

    If it's straightforward to make this better we can take a PR, but if it's complicated or has other side effects I'd consider this "not a defect"

  6. Ryan Cavanaugh (RyanCavanaugh)
    added this to the Backlog milestone on Feb 10, 2022
  7. lowr commented on Feb 10, 2022

    @lowr
    LowR (lowr)
    on Feb 10, 2022
    ContributorAuthor
    More actions

    It's correct to not error under snc: false because { p: undefined } is a legal return value

    I thought with #36696 A & B is equivalent never so all of the four functions aren't allowed to return anything even under snc: false? Just double checking.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Experience EnhancementNoncontroversial enhancementsNoncontroversial enhancementsSuggestionAn idea for TypeScriptAn idea for TypeScript

    Type

    No type

    Projects

    No projects

      Milestone

      • BacklogNo due date

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402503 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.