Skip to content

unsound type constraints #8459

Description

interface I {
    fn: <T>(t: T) => void;
}
interface X {
    x: number;
}
function toI<T extends X>() : I {
    return {
        fn: (t: T) => { // <-- expected a warning from the compiler that the type constraint cannot be enforced
            alert(t.x);
        }
    };
}
function test(i: I): void {
    i.fn({}); // <-- problem unnoticed
}
test(toI<X>()); // displays "undefined"

Activity

  1. malibuzios commented on May 4, 2016

    @malibuzios

    The example you gave was a bit too complicated for me to understand but I just wanted to mention that assignments of generic functions are not currently type-checked, in general.

    Perhaps until the implicit cast of generic function type parameters and return type to any during assignment is addressed, an error can be shown for assignments containing generic function types, in general?

    (There's no current error here)

    declare let f1: <T>(x: T) => T;
    declare let f2: (x: number) => void;
    
    f1 = f2; // Possible error/warning: "generic function types are not 
             // currently type-checked during assignments"

    I feel it would be a bit inappropriate to transfer the responsibility to the volunteers who maintain tslint.. Basically to report on an internal implementation issue of the compiler, which may be subject to change in the future, and is not actually related to the language or the design itself.

    Edit: corrected "declaration of generic functions" to "assignments of generic functions" and updated the example.

  2. malibuzios commented on May 4, 2016

    @malibuzios

    I've updated my comment based on this comment in #3410:

    When you call a function with a constrained type parameter, that function's type parameter constraint is checked. When you pass a function with a type parameter constraint, the constraint is not checked.

    And this one:

    Our assignability relation ignores generics and constraints in signatures. It just replaces all type parameters with any.

  3. zpdDG4gta8XKpMCd commented on Jun 17, 2016

    @zpdDG4gta8XKpMCd
    Author

    bump

  4. RyanCavanaugh commented on Aug 18, 2016

    @RyanCavanaugh
    Member

    I believe this is the same root cause as #8397 ?

  5. mhegazy commented on May 18, 2017

    @mhegazy
    Contributor

    tracked by #5616

  6. locked and limited conversation to collaborators on Jun 19, 2018
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