4 ms·

Yeah, ideally JSON.parse() returned `unknown`, but unfortunately that was added after the current type definition was already in widespread use, and therefore w

by Vinnl 6y ago

Yeah, ideally JSON.parse() returned `unknown`, but unfortunately that was added after the current type definition was already in widespread use, and therefore would be too much of a breaking change. Perhaps some day with a compiler flag.

TheCoelacanth 6y ago
Isn't that basically what the noImplicitAny flag does?
- Vinnl 6y ago
  Unfortunately no: that only errors when you do not add a type annotation and TypeScript can't infer anything better than `any`. JSON.parse(), however, is explicitly annotated to return any. See [1]. [1] https://www.typescriptlang.org/play?#code/PTAEEkDsDMFMCd6wCagC4HtQCNagIaQCeo08GAtqAFIDKA8gHIB0ADvvAM6wDknosAB6sANgEsAxmLSgkaAK7xI6Iq1gAuAFASMkTjMIBRQfgqjYANQ5j82EXgC8NBi3ZdYACgBEACVgiRLAB1DHgRZC8ASgBubV1ODHtmQIBzDyMTM3sreBs7WBjNTRAIGAQkVEwcPEISXAl8eW50AAsEPDF+SAw0FrFIFPQsfrh4Vrw0VTwySi1oeUgJNDFddFh9DzEsyWkRIgBBYkjQAG9NUAvQHT1E2GSMNK3RHbQ9w6JCgF9NIA https://www.typescriptlang.org/play?#code/PTAEEkDsDMFMCd6wCa...
  - WorldMaker 6y ago
    Yes, the type signature for JSON.parse() isn't inferred/deduced, it's explicit in lib.es5.d.ts (imported from lib.d.ts): https://github.com/microsoft/TypeScript/blob/master/lib/lib.es5.d.ts#L1059 https://github.com/microsoft/TypeScript/blob/master/lib/lib.... You could provide your own lib.d.ts with `unknown` type returned for JSON.parse. I'm almost surprised there isn't a standard stricter lib.d.ts, though I suppose that linters fill enough of those needs with their rulesets. Looking at GitHub issues surrounding it, it doesn't appear that there has been an explicit ask to switch the type signature to use `unknown`, probably the next closest was this one, where `unknown` is mentioned in a comment as a possibility but the comment is not addressed in follow up discussion: https://github.com/microsoft/TypeScript/issues/26993 https://github.com/microsoft/TypeScript/issues/26993 It would be a big breaking change though at this point, so they would probably be hesitant to do so. I thought I saw somewhere there was a proposal to add it as a compiler flag to treat all uses of `any` in lib.d.ts as `unknown`, but I have no idea what happened to that proposal and quick searches don't turn up anything.
    - Vinnl 6y ago
      Yeah I'd swear I'd seen that too, but I can't find it quickly either.
  - TheCoelacanth 6y ago
    Ah, I see my mistake. I have been getting warnings about JSON.parse, but they are coming from eslint@typescript-eslint/no-unsafe-assignment. It partially serves this purpose, but probably not as comprehensively as actually having it return unknown would.
eyelidlessness 6y ago
There are a lot of core language types that could substantially improve safety (not to mention inference), with anything explicitly `any` being obvious candidates. I feel like this should be a compiler/lib option for those of us who would opt into the breaking change for increased safety. But since it isn’t, augmentations may be an option. I’m not at my computer right now so I can’t verify that this would work, but you may be able to add an overload that returns `unknown`. Unfortunately with overloads, I’m pretty sure the built in types would be selected first without some additional specificity. This feels like a good opportunity for a safer standard library package wrapping globals, DOM, Node built-ins, etc.

by Vinnl 6y ago

TheCoelacanth 6y ago

Isn't that basically what the noImplicitAny flag does?

Vinnl 6y ago
Unfortunately no: that only errors when you do not add a type annotation and TypeScript can't infer anything better than `any`. JSON.parse(), however, is explicitly annotated to return any. See [1]. [1] https://www.typescriptlang.org/play?#code/PTAEEkDsDMFMCd6wCagC4HtQCNagIaQCeo08GAtqAFIDKA8gHIB0ADvvAM6wDknosAB6sANgEsAxmLSgkaAK7xI6Iq1gAuAFASMkTjMIBRQfgqjYANQ5j82EXgC8NBi3ZdYACgBEACVgiRLAB1DHgRZC8ASgBubV1ODHtmQIBzDyMTM3sreBs7WBjNTRAIGAQkVEwcPEISXAl8eW50AAsEPDF+SAw0FrFIFPQsfrh4Vrw0VTwySi1oeUgJNDFddFh9DzEsyWkRIgBBYkjQAG9NUAvQHT1E2GSMNK3RHbQ9w6JCgF9NIA https://www.typescriptlang.org/play?#code/PTAEEkDsDMFMCd6wCa...
- WorldMaker 6y ago
  Yes, the type signature for JSON.parse() isn't inferred/deduced, it's explicit in lib.es5.d.ts (imported from lib.d.ts): https://github.com/microsoft/TypeScript/blob/master/lib/lib.es5.d.ts#L1059 https://github.com/microsoft/TypeScript/blob/master/lib/lib.... You could provide your own lib.d.ts with `unknown` type returned for JSON.parse. I'm almost surprised there isn't a standard stricter lib.d.ts, though I suppose that linters fill enough of those needs with their rulesets. Looking at GitHub issues surrounding it, it doesn't appear that there has been an explicit ask to switch the type signature to use `unknown`, probably the next closest was this one, where `unknown` is mentioned in a comment as a possibility but the comment is not addressed in follow up discussion: https://github.com/microsoft/TypeScript/issues/26993 https://github.com/microsoft/TypeScript/issues/26993 It would be a big breaking change though at this point, so they would probably be hesitant to do so. I thought I saw somewhere there was a proposal to add it as a compiler flag to treat all uses of `any` in lib.d.ts as `unknown`, but I have no idea what happened to that proposal and quick searches don't turn up anything.
  - Vinnl 6y ago
    Yeah I'd swear I'd seen that too, but I can't find it quickly either.
- TheCoelacanth 6y ago
  Ah, I see my mistake. I have been getting warnings about JSON.parse, but they are coming from eslint@typescript-eslint/no-unsafe-assignment. It partially serves this purpose, but probably not as comprehensively as actually having it return unknown would.

eyelidlessness 6y ago

There are a lot of core language types that could substantially improve safety (not to mention inference), with anything explicitly `any` being obvious candidates. I feel like this should be a compiler/lib option for those of us who would opt into the breaking change for increased safety. But since it isn’t, augmentations may be an option. I’m not at my computer right now so I can’t verify that this would work, but you may be able to add an overload that returns `unknown`. Unfortunately with overloads, I’m pretty sure the built in types would be selected first without some additional specificity. This feels like a good opportunity for a safer standard library package wrapping globals, DOM, Node built-ins, etc.