keyof looks (at a glance) like a path type, conditionals look like they only judge type equalities (not values), and type guards are hooks to relate _runtime tests_ back to compile-time.
Conversation
Type equalities in this case are value equalities and can have interesting semantics because of the presence of literal, union, and intersection types types. Type guards can also be applied (and reduced) statically.
1
"Can be reduced" is fine; that's just optimizing away a runtime test. "Have legal semantics to leave a runtime test in" is the issue. That's gradual. Which is a perfectly fine, usable compromise! But it's also .. really not the same thing.
2
Again not trying to be a jerk, I've worked (for years!) on gradual systems, think they're a nice point in the design space. But to describe them as DT does a disservice to DT. The ability to punt anything bad to runtime makes the typing judgement mean something totally different.
1
I don't see what's not "real DT" about how conditionals are evaluated. They don't perform any work at runtime to narrow the type. If it can't reduce, it gets a union type, which can later match if it's possible to reduce, otherwise code must work with all branches.
2
If instead of a variable inhabiting a union type and literals, you got propositions of "variable = value" with disjunctions between them, would that be different in some fundamental way?
1
Literals are a subset of constants, equality is trivial. The equalities of interest are those between nontrivially-related symbolic values. Is the compiler obliged to deduce (or allowed to take evidence showing) x == y given nontrivial symbolic definitions of x and y?
1
Okay, I suspected this is what your gripe was. I am pretty sure the answer to this is "yes", thanks to records, unions, and type functions (though I'm not sure at what point things stop counting as trivial; you can't use full blown inductive datatypes here).
2
The triviality difference is crucial! Otherwise we're in case (c) of the earlier tweet: you can just constant-evaluate the values in types and compare them. The "full DT" problem is: what static tools do you give the user for expressing undecidable identities of types?
1
If you want to compare unknown literals, you can always create an array with the variable as a property, then use key mapping to reflect it as a type... I'm not sure if TS is yet smart enough to be able to reduce in this case, but it doesn't seem like any fundamental limitation.
3
1
As an aside, I live this adorable gis bot that keeps retweeting any tweet with mapping in it!