4 ms·

At this point, TypeScript should just let us define types using plain imperative TS code that will execute during static analysis. Might as well. type MyType<T

by brap 3y ago

At this point, TypeScript should just let us define types using plain imperative TS code that will execute during static analysis. Might as well. type MyType<T> = someFunc(T) Of course these functions might be typed too…

phpnode 3y ago
this is exactly what I want from the Types as Comments proposal[0] as I think it's the only way that types can feasibly become part of the language. It's hard to imagine how all of the concepts TS introduces via special syntax can be covered otherwise. [0] https://tc39.es/proposal-type-annotations https://tc39.es/proposal-type-annotations
- quickthrower2 3y ago
  That is a great idea. It also crystalizes the syntax so organisations other than MS can invest in building tooling as the target wont be as fast moving.
- brap 3y ago
  I mean this seems like a nice proposal, but I guess I’m missing something, how does it relate to my comment?
  - phpnode 3y ago
    That proposal aims to allow type annotations as part of JS, but to do that the parser needs to know when a type annotation starts (easy) and ends (hard), the only realistic ways that can be done at the moment is explicitly supporting all of the syntax TS introduces (which is bad for other type checkers) or restricting to a limited subset which would mean a lot of what TS supports would not be allowed, negating the usefulness of the proposal. What I'm saying is that if instead we said that all type annotations must follow existing JS grammar rules, with perhaps a couple of small additions, then we'd be able to support all sorts of complex type annotations in JS directly, using existing syntax. This would mean that TS's grammar would end up changing a bit, but that's a small price to pay for ongoing interoperability. For example, instead of type UserProperties = keyof typeof User; which is tied to TS's arbitrary syntax, and not supported in Flow, use type UserProperties = keyOf(typeOf(User));
bafe 3y ago
I recently had the insight- surely induced by reading something on HN or listening to some podcast- that types are simply functions from the set of all possible "values" to a logical value...
- brap 3y ago
  Yeah, a type is really just a set (in the mathematical sense). And a set can be defined by a function to {0, 1}. I don’t know if this function has a formal name, byt you can think of it as a “is this value a member of the set?” function.

by brap 3y ago

phpnode 3y ago

this is exactly what I want from the Types as Comments proposal[0] as I think it's the only way that types can feasibly become part of the language. It's hard to imagine how all of the concepts TS introduces via special syntax can be covered otherwise. [0] https://tc39.es/proposal-type-annotations https://tc39.es/proposal-type-annotations

quickthrower2 3y ago
That is a great idea. It also crystalizes the syntax so organisations other than MS can invest in building tooling as the target wont be as fast moving.
brap 3y ago
I mean this seems like a nice proposal, but I guess I’m missing something, how does it relate to my comment?
- phpnode 3y ago
  That proposal aims to allow type annotations as part of JS, but to do that the parser needs to know when a type annotation starts (easy) and ends (hard), the only realistic ways that can be done at the moment is explicitly supporting all of the syntax TS introduces (which is bad for other type checkers) or restricting to a limited subset which would mean a lot of what TS supports would not be allowed, negating the usefulness of the proposal. What I'm saying is that if instead we said that all type annotations must follow existing JS grammar rules, with perhaps a couple of small additions, then we'd be able to support all sorts of complex type annotations in JS directly, using existing syntax. This would mean that TS's grammar would end up changing a bit, but that's a small price to pay for ongoing interoperability. For example, instead of type UserProperties = keyof typeof User; which is tied to TS's arbitrary syntax, and not supported in Flow, use type UserProperties = keyOf(typeOf(User));

bafe 3y ago

I recently had the insight- surely induced by reading something on HN or listening to some podcast- that types are simply functions from the set of all possible "values" to a logical value...

brap 3y ago
Yeah, a type is really just a set (in the mathematical sense). And a set can be defined by a function to {0, 1}. I don’t know if this function has a formal name, byt you can think of it as a “is this value a member of the set?” function.