Skip to content

Correlated type constraint breaks under return type inference #32804

Open
Open
Correlated type constraint breaks under return type inference#32804
Labels
DiscussionIssues which may not have code impact

Description

@AnyhowStep
AnyhowStep
opened on Aug 11, 2019

TypeScript Version: 3.5.1

Search Terms:

return type, generic, constraint, assignable, correlated type

Code

type XStr = {x:string};
type XNum = {x:number};
type U = XStr|XNum;
type Args = { str : XStr, num : XNum };

declare function foo<
    ReturnT extends U,
    ValueT extends ReturnT["x"]
> (
    f : (args : Args) => ReturnT,
    value : ValueT
) : void;

/*
    Error as expected.

    Type 'string | number' does not satisfy the constraint 'string'.
    Type 'number' is not assignable to type 'string'.
*/
foo<XStr, string|number>(
    (args:Args) => args.str,
    ""
);
//Inferred type, foo<XStr, string | number>
foo(
    args => args.str,
    //Expected: Error
    //Actual: OK
    "" as string|number
);
//Inferred type, foo<XStr, string>
foo(
    //Added explicit type annotation to function params
    (args:Args) => args.str,
    /*
        Error as expected.

        Type 'string | number' does not satisfy the constraint 'string'.
        Type 'number' is not assignable to type 'string'.
    */
    "" as string|number
);

/////

/*
    Error as expected.

    Type '1' does not satisfy the constraint 'string'.
*/
foo<XStr, 1>(
    (args:Args) => args.str,
    1
);
//Inferred type, foo<XStr, 1>
foo(
    args => args.str,
    //Expected: Error
    //Actual: OK
    1
);
//Inferred type, foo<XStr, string>
foo(
    //Added explicit type annotation to function params
    (args:Args) => args.str,
    /*
        Error as expected.

        Type '1' does not satisfy the constraint 'string'.
    */
    1
);

Expected behavior:

I'm just calling it a correlated type because it reminds me of correlated subqueries from SQL.

  1. The constraint type of ValueT is dependent on the type of ReturnT.
  2. When f does not have parameters, or all parameters are explicitly annotated,
    ValueT is inferred correctly.
  3. When f has parameters that are not explicitly annotated,
    ValueT is inferred incorrectly.
  4. Attempting to explicitly set invalid type paramters will error as expected.
  • foo<XStr, string|number> should not be allowed
  • foo<XStr, 1> should not be allowed

Actual behavior:

  • foo<XStr, string|number> is allowed under inference
  • foo<XStr, 1> is allowed under inference

Playground Link:

Playground

Related Issues:

#32540 (comment)

#29133

A different, more complex example,
#14829 (comment)

[Edit]

Can someone come up with a better name for this?

I'm working on rewriting my type-safe SQL builder library and it relies on the return type of generic functions being inferred correctly. But it seems like return type inference just breaks in so many unexpected ways.

Anonymous callback functions are used a lot for building the WHERE, ORDER BY, GROUP BY, HAVING, JOIN, etc. clauses.

Since return type inference for generic functions is not robust, it's basically a blocker for me =(

Activity

  1. AnyhowStep
    changed the title [-]Correlated type constraint breaks [/-] [+]Correlated type constraint breaks under return type inference if function param type is also inferred[/+] on Aug 11, 2019
  2. AnyhowStep
    changed the title [-]Correlated type constraint breaks under return type inference if function param type is also inferred[/-] [+]Correlated type constraint breaks under return type inference[/+] on Aug 11, 2019

  3. AnyhowStep commented on Aug 11, 2019

    @AnyhowStep
    AnyhowStep
    on Aug 11, 2019
    ContributorAuthor

    From the behaviour of the above snippets and the inferred types displayed by the tooltips, it just feels like someone forgot to copy-paste some type inference logic or something.

    Like, the Inferred type, foo<XStr, 1> snippet's type is inferred as foo<XStr, 1> but it behaves like foo<U, 1>

  4. AnyhowStep commented on Aug 11, 2019

    @AnyhowStep
    AnyhowStep
    on Aug 11, 2019
    ContributorAuthor

    !@#$ YES!
    I HAVE FINALLY FIGURED OUT A WORKAROUND!

    type XStr = {x:string};
type XNum = {x:number};
type U = XStr|XNum;
type Args = { str : XStr, num : XNum };

declare function foo<
    ReturnT extends U,
    ValueT extends ReturnT["x"]
> (
    ...f : (
        (
            ReturnT extends U ?
            [((args : Args) => ReturnT), ValueT] :
            never
        )
    )
) : ValueT;

/*
    Error as expected.

    Type 'string | number' does not satisfy the constraint 'string'.
    Type 'number' is not assignable to type 'string'.
*/
foo<XStr, string|number>(
    (args:Args) => args.str,
    ""
);
//Inferred type, foo<XStr, string>
foo(
    args => args.str,
    /*
        Error as expected.

        Type 'string | number' does not satisfy the constraint 'string'.
        Type 'number' is not assignable to type 'string'.
    */
    "" as string|number
);
//Inferred type, foo<XStr, string>
foo(
    //Added explicit type annotation to function params
    (args:Args) => args.str,
    /*
        Error as expected.

        Type 'string | number' does not satisfy the constraint 'string'.
        Type 'number' is not assignable to type 'string'.
    */
    "" as string|number
);

/////

/*
    Error as expected.

    Type '1' does not satisfy the constraint 'string'.
*/
foo<XStr, 1>(
    (args:Args) => args.str,
    1
);
//Inferred type, foo<XStr, string>
foo(
    args => args.str,
    /*
        Error as expected.

        Type '1' does not satisfy the constraint 'string'.
    */
    1
);
//Inferred type, foo<XStr, string>
foo(
    //Added explicit type annotation to function params
    (args:Args) => args.str,
    /*
        Error as expected.

        Type '1' does not satisfy the constraint 'string'.
    */
    1
);

//Return type is "hello" as expected
foo(
    args => args.str,
    "hello"
);

//Return type is 42 as expected
foo(
    args => args.num,
    42
);

    Playground

    The magic is here,

        ...f : (
        (
            ReturnT extends U ?
            [((args : Args) => ReturnT), ValueT] :
            never
        )
    )

    It turns ReturnT into a union of tuples (2-tuples, in this case), and then uses rest parameters

    [Edit]

    After spending a good chunk of my Saturday trying to think of a workaround, I suddenly came up with this idea after randomly remembering my comment here,
    #32596 (comment)

    I had brought up using tuples and rest parameters as a possible workaround for that issue (there was a different, better way to express it in that issue, though)

    [Edit]

    Wait... I just realized that workaround doesn't use ValueT. I must be seriously tired to be making silly mistakes.

    Brb. Gonna' fix that up. (Or try).

    My use case requires both ReturnT and ValueT and does magic with it in the return type.

    [Edit]

    Fixed it to use ValueT

    [Edit]

    Nevermind. I tried to adapt it to fit my actual use case and this workaround broke apart.
    For one, I want to give my ReturnT the option to be a union type.

    So, I can't have the conditional type perform distribution.
    If it doesn't distribute, we go back to square 1 with the inference problems.
    Playground

  5. AnyhowStep commented on Aug 11, 2019

    @AnyhowStep
    AnyhowStep
    on Aug 11, 2019
    ContributorAuthor

    This is closer to my personal use-case,

    type XStr = {x:string};
type XNum = {x:number};
type U = XStr|XNum;
type Args = { str : XStr, num : XNum };

declare function foo<
    ReturnT extends U,
    ValueT extends ReturnT["x"]
> (
    ...f : (
        (
            //Uses `& ReturnT["x"]` to make this work
            [((args : Args) => ReturnT), ValueT & ReturnT["x"]]
        )
    )
) : ValueT;

//OK!
//Inferred type, foo<XStr | XNum, string | number>
foo(
    args => Math.random() > 0.5 ? args.str : args.num,
    "" as string|number
);

/*
    Error as expected.

    Type 'string | number' does not satisfy the constraint 'string'.
    Type 'number' is not assignable to type 'string'.
*/
foo<XStr, string|number>(
    (args:Args) => args.str,
    ""
);
//Inferred type, foo<XStr, string|number>
foo(
    args => args.str,
    /*
        Expected: Error
        Actual: OK
    */
    "" as string|number
);
//Inferred type, foo<XStr, string>
foo(
    //Added explicit type annotation to function params
    (args:Args) => args.str,
    /*
        Error as expected.

        Type 'string | number' does not satisfy the constraint 'string'.
        Type 'number' is not assignable to type 'string'.
    */
    "" as string|number
);

/////

/*
    Error as expected.

    Type '1' does not satisfy the constraint 'string'.
*/
foo<XStr, 1>(
    (args:Args) => args.str,
    1
);
//Inferred type, foo<XStr, 1>
foo(
    args => args.str,
    /*
        Expected: Error
        Actual: OK
    */
    1
);
//Inferred type, foo<XStr, string>
foo(
    //Added explicit type annotation to function params
    (args:Args) => args.str,
    /*
        Error as expected.

        Type '1' does not satisfy the constraint 'string'.
    */
    1
);

//Return type is "hello" as expected
foo(
    args => args.str,
    "hello"
);

//Return type is 42 as expected
foo(
    args => args.num,
    42
);

    Playground

    I need to allow a union type to be returned and handle that accordingly.
    My actual use case needs to use UnionToIntersection<>, though.

  6. AnyhowStep commented on Aug 11, 2019

    @AnyhowStep
    AnyhowStep
    on Aug 11, 2019
    ContributorAuthor

    Seems like using UnionToIntersection<> breaks it,
    NoInfer<> doesn't help, either.

    type UnionToIntersection<U> = (
    (
        U extends any ? (k: U) => void : never
    ) extends (
        (k: infer I) => void
    ) ? I : never
);

type XStr = {x:{propStr:string}};
type XNum = {x:{propNum:number}};
type U = XStr|XNum;
type Args = { str : XStr, num : XNum };

declare function foo<
    ReturnT extends U
> (
    ...f : (
        (
            [
                ((args : Args) => ReturnT),
                UnionToIntersection<
                    ReturnT["x"]
                >
            ]
        )
    )
) : void;

foo(
    args => Math.random() > 0.5 ? args.str : args.num,
    //OK!
    //Error: Property 'propNum' is missing
    {
        propStr : "hello",
    }
);
foo(
    args => Math.random() > 0.5 ? args.str : args.num,
    //OK!
    //Error: Property 'propStr' is missing
    {
        propNum : 42,
    }
);
foo(
    args => Math.random() > 0.5 ? args.str : args.num,
    //OK!
    //No error
    {
        propStr : "hello",
        propNum : 42,
    }
);

//Expected: foo<XStr>
//Actual  : foo<U>
foo(
    args => args.str,
    //Expected: OK
    //Actual  : Property 'propNum' is missing
    { propStr : "hello" }
);

type NoInfer<T> = [T][T extends any ? 0 : never];
declare function foo2<
    ReturnT extends U
> (
    ...f : (
        (
            [
                ((args : Args) => ReturnT),
                UnionToIntersection<
                    //NoInfer doesn't seem to work here
                    NoInfer<ReturnT>["x"]
                >
            ]
        )
    )
) : void;
//Expected: foo2<XStr>
//Actual  : foo2<U>
foo2(
    args => args.str,
    //Expected: OK
    //Actual  : Property 'propNum' is missing
    { propStr : "hello" }
);

    Playground

    Better repro of how UnionToIntersection<> wrecks this workaround,
    Playground

  7. RyanCavanaugh commented on Aug 16, 2019

    @RyanCavanaugh
    Ryan Cavanaugh (RyanCavanaugh)
    on Aug 16, 2019
    Member

    I'm ignoring the long posts other than the OP 😐

    Why isn't the function definition just this?

    declare function foo<ReturnT extends U>(
    f: (args: Args) => ReturnT,
    arg: ReturnT["x"]
): void;

    Alternatively it seems like you need a non-inferential type parameter usage operator? #14829

  8. Ryan Cavanaugh (RyanCavanaugh)
    added
    DiscussionIssues which may not have code impact
    on Aug 16, 2019

  9. AnyhowStep commented on Aug 16, 2019

    @AnyhowStep
    AnyhowStep
    on Aug 16, 2019
    ContributorAuthor

    I need arg to possibly be a subtype of ReturnT["x"]

    It's used for the return type in my actual use case. (The return type was void in my OP to simplify)

    All attempts at using the workarounds for non inferential type param usage break for this use case, at the moment =/

    The function represents a column in SQL. The return type is the type of the column.

    The ValueT represents a possible value of the column.

    Let's say we have this query being built by the library,

    SELECT
  myTable.myColumn
FROM
  myTable

    Let's say the type of the column is null|number.

    If we add this WHERE clause,

    SELECT
  myTable.myColumn
FROM
  myTable
WHERE
  myTable.myColumn <=> 1

    Then we can statically narrow the type of myColumn in the query to 1, without even executing the query.

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

    DiscussionIssues which may not have code impact

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions