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

inconsistencies with string literal values after always use literal types pr #13705

Closed
zpdDG4gta8XKpMCd opened this issue Jan 26, 2017 · 5 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@zpdDG4gta8XKpMCd
Copy link

zpdDG4gta8XKpMCd commented Jan 26, 2017

nightly build jan 26

interface Wrapped<T> {
    wrapped: T;
}
function wrap<T>(value: T): Wrapped<T> {
    return { wrapped: value };
}

const one = 'test'; // one is 'test'
const oneWrapped = wrap(one); // oneWrapped is Wrapped<string>

const another: 'test' = 'test'; // another is 'test'
const anotherWrapped = wrap(another); // anotherWrapped is Wrapped<'test'> <--- WHY?

is that how #10676 supposed to work?

@zpdDG4gta8XKpMCd
Copy link
Author

@ahejlsberg you might be interested

@mhegazy
Copy link
Contributor

mhegazy commented Jan 26, 2017

is that how #10676 supposed to work?

yes. the inferred literal type is not widened in two cases, 1. it is present unwrapped in the output, e.g. identity function, 2. if the type parameter is constraint to its base type, e.g. string. explicit literal types are never widened.

@mhegazy mhegazy added the Working as Intended The behavior described is the intended behavior; this is not a bug label Jan 26, 2017
@zpdDG4gta8XKpMCd
Copy link
Author

this is super counterintuitive

@mhegazy
Copy link
Contributor

mhegazy commented Jan 27, 2017

There is a long discussion in and in #10676,
#10898 and #11126 about why it does work this way. all other options were less intuitive overall.

@zpdDG4gta8XKpMCd
Copy link
Author

i missed #11126 somehow, closing

@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
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

2 participants