What the heck are reverse mapped types?

You know the saying that everyone who drives slower than you is a moron, and everyone who drives faster than you is a lunatic? You seem to be in a mode of "every type system more powerful than what I'm used to is unnecessary", and I'm sure you believe the other half: "every type system weaker than what I'm used to is for morons".

Keep in mind, this article is about a detail inside the compiler that makes type inference "just work" seemingly magically. It's not a detail you need to worry about. If you think powerful type inference and mapped types are just for the "perception of improved type safety", you are revealing that you have simply never attempted to learn them.

> if you have powerful type system, it does not mean it warrants pushing it to its limits, and strikes me as the behavior everyone tends to suffer from in the middle of a learning process of a new tool.

These kinds of features are more for library developers. You should be very glad that the people who make the libraries you rely on every day have access to these kinds of features, because when they do their job well, things "just work" so invisibly that you have no way of appreciating what's actually going on in the background. These "astronaut developers" that you disrespectfully deride are the entire reason you're able to do your job at all. Have a little respect.

Being able to put your types in as an arg and keep the other parts in sync in the editor without having to write a bunch of boilerplate just to define one-off types. I find it speeds up dev and reduces the amount of application code that needs testing overall.

> This is the lingo used in the compiler's source code, in the PRs and in the issues on GitHub.

> When you have to infer the T from a MappedType<T>, you are inverting the action of the MappedType. There is a dedicated part in the compiler for doing that.

Source: https://www.reddit.com/r/typescript/comments/1elj65m/comment...

It incorporates concepts from set theory, you have unions T|U, intersections T&U, comprehensions { [T in U]: e(T) }, conditionals (T extends U ? A : B ), pattern matching (infer T), and the typeof operator is like a poor man’s dependent typing.

While you could certainly express all of these concepts in a language with dependent types, you can’t emulate the inference rules (the subject of TFA), so it can be said that TypeScript’s type theory is unique.

While technically used like types, TypeScript "types" are really compile-time values that happen to be also usable for constraining usual run-time values like types. These compile-time values themselves do not have much types, so you can easily get errors from compile-time evaluations (which is different from compile-time type errors!). Likewise, most TypeScript type-level constructs are really long-winded methods to do the compile-time computation and have no straightforward equivalents in type systems that do guarantee the soundness and coherence (which have specific definitions).

I wouldn't say this. It can bring complications, yes: but only because like a lot of expressive tools people will over-engineer things with them (probably like this sentence)

To me, Typescript saved JavaScript from under-constraining. It's bringing me some peace of mind.

1) the destructive yet not helpful nature of your post. What are better alternatives to write JavaScript than TS? Elm and flow are not.

2) not realizing that any powerful type system (or language) has advanced concepts, this isn't exclusive to TypeScript

3) Not realizing this is mostly a tool for library authors to provide better inference to API consumers

4) Last but not least, 99% of TypeScript users can't even tell what a mapped type is (it's in the docs) nor define it or say when to use it, people don't even bother to read the docs fundamentals so attitudes like yours are unsurprising

5) Typescript is verbose, but very simple to follow and read if you know the basics. It's unmaintainable only because people don't bother to master any topic