Constraint Types Proposal

[dead-claudia]

Edit: Now a gist, with all the previous edits erased.

See this gist for the current proposal. Better there than a wall of text here.

[asfernandes]

Why not use a ternary operator?

Instead of:

let other: (value is number: string | value is string: boolean)

This:

let other: (value is number ? string : value is string ? boolean)

Looks less confusing for me.

[zpdDG4gta8XKpMCd]

this is what they call dependent types, isnt it?

if so, is predicate alone looks too constraining (pun intended) it should be any predicate:

type T<A> = string when A is number && A % 2 === 0;
type T<A> = number when A is string && A.length > 1;

[dead-claudia]

@Aleksey-Bykov It's not quite dependent types, because values cannot be lifted to types, nor can types be lifted to values. This proposal only allows proper type -> type functions (we already have value -> value functions), but it's missing the other two cases. And no, typeof does not provide that ability, because it merely grabs the type of that binding, and is equivalent to using a type alias with explicit types.

a is T already exists for things like this:

interface ArrayConstructor {
    isArray(value: any): value is any[];
}

And Is<Type, Super> is a static instanceof assertion, and you can use it like this:

function staticAssert<T>() {}
declare const value: any

if (Array.isArray(value)) {
    staticAssert<Is<typeof value, any[]>>()
} else {
    staticAssert<NotA<typeof value, any[]>>()
}

[dead-claudia]

@asfernandes

The reason I chose not to use a ternary is because of two reasons:

1. It visually conflicts with nullable types, and is also much harder to parse (you have to parse the whole expression before you know if the right side is a nullable type):

   type Foo = (value is number ? string : boolean)
   type Foo = (value is number? ? string : boolean)

2. Types may have more than two different conditions (e.g. with overloaded types), and the ternary operator doesn't make for very readable code in this case.

[zpdDG4gta8XKpMCd]

i suggest you list type overloads one per line (rather than all in the samr `|` separated list), it's cleaner, proven to work, doesn't need 3nary operator

…

On Jan 8, 2017 8:03 PM, "Isiah Meadows" ***@***.***> wrote: @asfernandes <https://github.com/asfernandes> The reason I chose not to use a ternary is because of two reasons: 1. It visually conflicts with nullable types, and is also much harder to parse (you have to parse the whole expression before you know if the right side is a nullable type): type Foo = (value is number ? string : boolean)type Foo = (value is number? ? string : boolean) 2. Types may have more than two different conditions (e.g. with overloaded types), and the ternary operator doesn't make for very readable code in this case. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#13257 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA5PzZI0WDoZcUpIVQ6w65Z8dCdTSOecks5rQYdlgaJpZM4LZObU> .

[dead-claudia]

@Aleksey-Bykov TypeScript only cares about newlines for ASI, and there's no other precedent for newline significance. Additionally, I intentionally phrased the constraint types as a union of constraints, so they could be similarly narrowed with control flow (just as current union types can be), and that's why I used the | union operator.

As for why I chose a union instead of separate type overloads, here's why:

1. I don't need to create a dedicated impossibility type, and can just declare any particular token as a keyword. This limits the compatibility impact and simplifies parsing greatly.

2. Type aliases will remain to always resolve to something, so it doesn't involve rewriting core logic that relies on this assumption. And the TypeScript code base has historically been a giant ball of mud with assumptions like these littered across the code base.

3. I don't have to create a type alias to define such a type every time. This not only provides flexibility (I can define one any time I want), but it also lets me create lambda return types that depend on the types of their parameters, even if they're unions or generics whose type is detected at runtime. The latter is plainly not possible with named types.

4. Return types can statically depend on the generic type parameter as well as the parameters themselves. This is a must for capturing and properly constraining Promise.resolve as a standalone method, since it's literally impossible to ever return a Promise<Thenable<T>> due to thenable coercion.

I did in fact already consider the idea of type overloads, and initially tried that route before posting this. The above issues, especially the first three, are why I elected to go a different route instead.

[Artazor]

@isiahmeadows, your proposal is what I would like to see in TypeScript.
However, I do not think that this is the union. It is the ordered selection, not all alternatives together (like in PEG). And narrowing should be designed from the scratch for this kind of types.

I would like to use a / instead of | to emphasize that the order matters (the same intuition as PEG)

[Artazor]

However, I wanted to move in the direction of type decomposition via switch-types

type CoerceToValue<T> = switch(T)  { 
     case<V> Thenable<V>: V;
     default: T;
}  

or even

type CoerceToValue<T> = switch(T)  { 
     case<V> Thenable<V>: CoerceToValue<V>;
     default: T;
}  

[dead-claudia]

@Artazor That might work, too, but I have my reservations in terms of expressiveness. How would you do something equivalent to my Super<T> type (any supertype of T), and how would you constrain the T correctly with Promise<T> (where T cannot be a thenable)?

// Using my proposal's syntax
type Super<T> = (U in T extends U: U);
interface Promise<T extends (T extends Thenable<any>: * | T: T)> {}

[bobappleyard]

What about never as impossibility assertion?

[dead-claudia]

@bobappleyard Can't use it because it's already a valid return type (specifically a bottom type, a subtype of every type).

function error(): never {
  throw new Error()
}

I need an impossibility type, where even merely matching it is contradictory.

[dead-claudia]

Note to all: I updated my proposal some to aid in readability.