Subtraction types

[zpdDG4gta8XKpMCd]

Another type-safety measure. Sometimes it's desired to limit what developers can do with a value. Not allowing them to get to certain properties of it looks sufficient.

Example: We render HTML elements to PDF on the client side. In order to do so we need to run element.getBoundingClientRect to get a bounding box in effect. It is an expensive operation that we wish could only be done once and then the result of it would be passed around along with the element to be rendered. Unfortunately nothing stops developers from ignoring that result and running the same method again and again as long as they can get to element.getBoundingClientRect. Now I wish I could strip that method so no-one can see it once the box is calculated. Subtaction types would solve the problem.

type HTMLDivSpecifics = HTMLDivElement - Element;

Proposal

add a type operator that produces a new type out of 2 given types according to the rules that follow:

type C = A - B;

This feature would require a new negated type like number ~ string which is a number that cannot take number & string.

As far as the precedence of new type operator, it should go:

1. intersection &
2. union |
3. subtraction -

so that number & boolean | string - string, means ((number & boolean) | string) - string

Generics

• should produce a yet to be resolved type, should be stored as an expression which will produce either a type or an error when all type parameters are known

type Minus<A, B> = A - B; // yet to be calculated

Primitives

• if the left type (minued) isn't a sub-type of the right type (subtrahend) the - operation should result to an type error
• never and any should be specially handled

type C = number - number; // {}
type C = number - {}; // number
type C = {} - number; // error
type C = number - string; // error
type C = number - 0; // number ~ 0

type C = number | string - boolean; // error
type C = number - void | null | undefined; // error

type C = number - any; // {}
type C = any - any; // any
type C = any - number; // any ~ number
type C = any - never; // error;
type C = never - any; // error;
type C = number - never; // error
type C = never - number; // error
type C = never - never; // error

type C = number | string - string; // number
type C = number - number | string; // {}
type C = number | string - {}; // number | string

type C = number & string - boolean; // error
type C = number & string - string; // number ~ string

Products

• only matching properties should be considered, non-matching properties of the left type should stay intact, non-matching properties of the right type should be disregarded
• if the names of 2 properties match their types are subject for - operation that produces the type of the resulting property of the same name
• if applying - on 2 properties of the same name gives {}, the property gets dropped from the resulting type

type C = {} - { x: number }; // {}
type C = { x: number } - {}; // { x: number }
type C = { x: {} } - { x: number }; // error
type C = { x: number } - { x: {} }; // { x: number }
type C = { x: number } - { y: number }; // { x: number }
type C = { x: number } - { x: number }; // {}
type C = { x: number | string } - { x: string }; // { x: number }
type C = { x: number & string } - { x: string }; // { x: number ~ string }
type C = { x: number } - { x: string }; // error

Functions (2 certain signatures)

• both functions must have the same number of parameters, otherwise it's an error
• types of corresponding parameters are subject to the - operator
• types of results must 100% match and should be kept intact, otherwise it's an error
• if - on 2 parameters gives {} the resulting parameter is {}
• if all resulting parameters are {} the resulting type is {}

type C = ((x: number) => string) - ((x: number) => string); // {}
type C = ((x: number) => number) - ((x: number) => number); // (x: {}) => number
type C = ((x: number | string) => string) - ((x: string) => string); // (x: number) => string
type C = ((x: number) => string) - ((x: string) => string); // error
type C = ((x: number | string) => string) - (() => string); // error
type C = (() => string) - ((x: number) => string); // error

Overloads

• to be continued...

[RyanCavanaugh]

What about something like this?

interface DoNotCalculateAgain {
    getBoundingClientRect(): void;
}

let y: DoNotCalculateAgain & HTMLElement;
// z: void, so an inevitable compile error on use
let z = y.getBoundingClientRect();

[zpdDG4gta8XKpMCd]

hm, didn't know it works this way, could be useful for anything that doesn't return void, which is better than nothing

[danquirk]

Alternatively, wouldn't you have the object type itself guard against this type of re-initialization? ie

class MyElement {
    private boundResult = ...
    public getBoundingClientRect() {
        if(boundResult) return boundResult
        ...
        boundResult = ...
        return ...
    }
}```

[zpdDG4gta8XKpMCd]

1. we are talking about a standard DOM element interface, there is no place to put that safer wrapper you are talking about
2. not letting see a method results to statically verified and more correct code as opposed to making assumptions at runtime
3. honestly there are a lot of ways to deal with this situation without involving subtraction types, it's not even a problem in the first place, just an example to show where a feature like this can be helpful

Another example: to support the principle of interface segregation, instead of passing a thick interface to a specialized function that only needs a few properties we could have cut it to a sub-type that would be just sufficient enough to run leaving all irrelevant members outside (same can be done today by employing existing features, however at a price of larger code base and requiring more maintenance)

[stepancar]

@Aleksey-Bykov , @RyanCavanaugh.
Whats status of this issue?

[zpdDG4gta8XKpMCd]

open, needs a proposal, considered as a suggestion

[mhegazy]

Please see https://github.com/Microsoft/TypeScript/wiki/FAQ#what-do-the-labels-on-these-issues-mean for label description.

[stepancar]

@mhegazy, sorry, thank you!

[rederteph]

It seems like very useful functionality.

[Ciantic]

I think there should be more set operations over the fields, like subtraction there could be intersection of fields:

interface A {
  firstName: string;
  lastName: string;
}

interface B {
  firstName: string;
  grade: string;
}

// "Set operation of intersection of fields"
let c: typeof A fieldIntersection B

// would mean c is now
interface C {
  firstName: string;
}

Not to be confused with intersection types which are actually field union.

There are use cases for field subtraction and field intersection in a LINQ like type-safe SQL builders.

[zpdDG4gta8XKpMCd]

numbers without NaN would be another interesting case for subtraction types: type AlwaysANumber = number - NaN

#9407 (comment)