Skip to content

Function Generic is unknown if argument has NoInfer<Generic> but returns the Generic #60922

Closed as not planned

Description

🔎 Search Terms

  • Generic
  • NoInfer
  • Unknown

🕗 Version & Regression Information

Still the case in the latest 5.7.2.

⏯ Playground Link

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

💻 Code

export declare function linkedSignal<S, D>(options: {
    source: () => S;
    computation: (source: NoInfer<D>) => D;
}): D;

const signal = linkedSignal({
    source: () => 3,
    computation: (s) => 3 
})

🙁 Actual behavior

signal is unknown

🙂 Expected behavior

signal is number

Additional information about the issue

I wasn't sure, but it could be a duplicate of #60544.

Activity

  1. Andarist commented on Jan 6, 2025

    @Andarist
    Contributor

    This, indeed, looks like a simpler version of #60544

    I don't quite see how this could be implemented beyond some very basic support for a small set of scenarios. The return type of a function very often depends (even if indirectly) on its parameters types. Like, how would you determine what D should be here?

    const signal = linkedSignal({
        source: () => 3,
        computation: (s) => s
    })

    Would unknown be a satisfiable inference here? What about this one?

    const signal = linkedSignal({
        source: () => 3,
        computation: (s) => {
          return Math.random() > 0.5 > 1 : s;
        }
    })
  2. JeanMeche commented on Jan 6, 2025

    @JeanMeche
    ContributorAuthor

    I think I get your point.

    number | unknown narrows down to unknown, so unknown is the reseanable inference.

  3. typescript-bot commented on Jan 10, 2025

    @typescript-bot
    Contributor

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

  4. Harpush commented on Jan 10, 2025

    @Harpush

    This, indeed, looks like a simpler version of #60544

    I don't quite see how this could be implemented beyond some very basic support for a small set of scenarios. The return type of a function very often depends (even if indirectly) on its parameters types. Like, how would you determine what D should be here?

    const signal = linkedSignal({
    source: () => 3,
    computation: (s) => s
    })
    Would unknown be a satisfiable inference here? What about this one?

    const signal = linkedSignal({
    source: () => 3,
    computation: (s) => {
    return Math.random() > 0.5 > 1 : s;
    }
    })

    Mateusz Burzyński (@Andarist) Why won't that work though?

    const signal = linkedSignal({
        source: () => 3,
        computation: (s): number => {
          return Math.random() > 0.5 > 1 : s;
        }
    })

    Especially as s has noinfer which means it should infer from the return type that was explicitly given.

  5. Andarist commented on Jan 13, 2025

    @Andarist
    Contributor

    Harpush this one could work, see: #60964

  6. locked as resolved and limited conversation to collaborators on Oct 22, 2025
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

    DuplicateAn existing issue was already created

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions