Repository navigation
Present somehow to user that literal type is a widening literal type #11181
Description
I'm just adding the task here for your consideration (because it was buried in a comment in some other bug).
With #11126
we have now (literal types and widening literal types) and new rules to remember to understand the resulting inferred type for mutable location:
| Type | Inferred type for mutable location |
|---|---|
| 'foo' | 'foo' |
| widening 'foo' | string |
| 'foo' | 'bar' | 'foo' | 'bar' |
| 'foo' | widening 'bar' | string |
| 'foo' | widening 'foo' | 'foo' |
etc..
Now using this code:
// File: SomeonesLibrary.ts
declare var val:boolean
export const a : 'a' | 'b' = (val) ? 'a' : 'b'
export const b = (val) ? 'a' : 'b'// File: OurCode.ts
import * as test from './SomeonesLibrary'
// VSCode will show:
// test.a -> type: 'a' | 'b'
// test.b -> type: 'a' | 'b'
let a1 = test.a // Type: 'a' | 'b'
let a2 = test.b // Type: string --->> why ???????
// not easy to answer without going to source code of someones files
// to understand TS behavior
// Assume user did not check what TS infered for `a1` and `a2` because
// natural thinking is that it is of type `a | b`
a1 = 'c' // Throws error nicely
a2 = 'c' // No error shown so what I'm asking is - make it more clear for user to figure out why TS behaves in a way it behaves (because right now presenting Type: a | b for both cases is misleading and can cause some bugs (or rather prevent bugs from detecting)
Maybe VSCode could show:
// test.a -> type: 'a' | 'b'
// test.b -> type: widening 'a' | widening 'b' # or different color Thanks a lot for consideration
Activity
RyanCavanaugh commentedon Sep 27, 2016
I'm not sure this reduces net confusion, but we can consider it
RyanCavanaugh commentedon Nov 15, 2016
It's not at all obvious what value this would provide -- anyone capable of understanding what that would mean probably wouldn't be confused in the first place, whereas anyone who doesn't know what
widening "foo"means is going to be really lost