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

another strangeness #5741

Closed
zpdDG4gta8XKpMCd opened this issue Nov 20, 2015 · 4 comments
Closed

another strangeness #5741

zpdDG4gta8XKpMCd opened this issue Nov 20, 2015 · 4 comments
Labels
By Design Deprecated - use "Working as Intended" or "Design Limitation" instead

Comments

@zpdDG4gta8XKpMCd
Copy link

// tag types: https://github.com/Microsoft/TypeScript/issues/4895
const enum Tag {} // <-- tag (hopefully nominal) type to indicate some assertion taken place over a string value

function foo(
    values: (string & Tag)[],
    callback: (one: string & Tag) => number // <-- only strings that have satisfied the assertion are welcome here
) {
    return undefined;
}

function bar(one: string): number { // <-- function that doesn't require its parameter to be marked
    return undefined
}

foo([], bar); // <-- no problem... why is bar an ok argument? didn't we ask for a function that requires a string & enum?
// are enums not nominal? why is it ok to ignore it here?
@weswigham
Copy link
Member

Function Argument Bivariance

When comparing the types of function parameters, assignment succeeds if either the source parameter is assignable to the target parameter, or vice versa. This is unsound because a caller might end up being given a function that takes a more specialized type, but invokes the function with a less specialized type. In practice, this sort of error is rare, and allowing this enables many common JavaScript patterns.

string & Marker is assignable to string, so (one: string) => number is assignable to (one: string & Marker) => number

@zpdDG4gta8XKpMCd
Copy link
Author

oh god... so f...ing annoying, hate typescript

@DanielRosenwasser DanielRosenwasser added the By Design Deprecated - use "Working as Intended" or "Design Limitation" instead label Nov 21, 2015
@RyanCavanaugh
Copy link
Member

🌹

@zpdDG4gta8XKpMCd
Copy link
Author

RIP tag types: #4895

@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
By Design Deprecated - use "Working as Intended" or "Design Limitation" instead
Projects
None yet
Development

No branches or pull requests

4 participants