Negated types

[zpdDG4gta8XKpMCd]

Sometimes it is desired to forbid certain types from being considered.

Example: JSON.stringify(function() {}); doesn't make sense and the chance is high it's written like this by mistake. With negated types we could eliminate a chance of it.

type Serializable = any ~ Function; // or simply ~ Function
declare interface JSON {
   stringify(value: Serializable): string;
}

Another example

export NonIdentifierExpression = ts.Expression ~ ts.Identifier

[wclr]

It is interesting, it is possible to achieve somehow?

[siegebell]

Edit: this comment probably belongs in #7993 instead.

Aleksey-Bykov This would allow unions with a catch-all member, without overshadowing the types of the known members.

interface A { type: "a", data: number }
interface B { type: "b", data: string }
interface Unknown { type: string ~"a"|"b", data: any }
type ABU = A | B | Unknown

var x : ABU = {type: "a", data: 5}
if(x.type === "a") {
  let y = x.data; // y should be inferred to be a number instead of any
} 

[SalathielGenese]

Following Mohamed Hegazy (@mhegazy) request at #18280, I copy-paste this suggestion here...

---

I upvote A & !B especially the !B part... Over Exclude from #21847

[jack-williams]

Do negated types rely on completeness for type-checking?

[zpdDG4gta8XKpMCd]

I think you should never put a question of what exactly any - MyClass is. I think negated types should be evaluated loosely lazily and only when it comes to typechecks against certain types.

[jack-williams]

I agree. Is that not sort of like many types now, e.g. number. You never consider how to construct number because it's infinite: only test that a value belongs to it when you need it. What would be the (lazy) procedure for checking that T belongs to A - B, or !B?

[SalathielGenese]

// exclude all match of T from U
U & !T

// extract all match of T within U
T & U

// type to all but T
!T

What would be the (lazy) procedure for checking that T belongs to A - B, or !B?

T extends (A & !B)
// or
T extends !B

[zpdDG4gta8XKpMCd]

not until all type parameters (A, B and T in your example) are resolved to concrete types (string, MyClass, null) can you tell what A - B is

[zpdDG4gta8XKpMCd]

so the procedure would be:

1. keep type expressions unevaluated until all type parameters are resolved
2. once all type parameters are known, replace them with the concrete types and see if the expression makes any sense

[jack-williams]

Understood! I guess my question is when you have some concrete types, say A, B, C, and you want to know if A is assignable to B - C, is it something like.

• if A is assignable to B
• and A is not assignable to C
• then A is assignable to B - C.

For A assignable to !C it would just be is A not assignable to C. (Thanks Salathiel Genese (@SalathielGenese))

Sorry if that's not clear!

[SalathielGenese]

For A assignable to !C it would just be is A not assignable to B.

I think you meant A not assignable to C

[zpdDG4gta8XKpMCd]

not sure if you can apply sort of a type algebra here, because it's unclear how assignability relates to negation

what you can do is to build a concrete type out of B - C and name it D (provided both B and C are known) and then ask a question whether or not A is assignable to the concrete type D

my naive 5 cents

question still stands what to do when B is too broad like any

[SalathielGenese]

I think a cleaner way to see B - C would be much like a type constraint rather a type by essence.