fleshing out type operators (discussion)

Question

fleshing out type operators (discussion)

KiaraGrouwstra opened this issue 8 years ago · 54 comments

This is a discussion thread where I'd like to give a high-level overview of the type-level operations (as opposed to expression-level) that we can and can not yet do today.

This differs from the TS roadmap by identifying holes, while complementing the issues list by trying to show some of the bigger picture, the goal being to see what issues tie into which points, and how we could address them.

I'd like stimulate discussion on how we could fill the holes here; for all I know there are holes we can find solutions to with no changes to TS!

Below is my list of imaginable basic type operations. The reason I focus on these is that, with basic operators down, most more complicated use-cases could be addressed simply by combining these. Names are based on my implementations here.

Additions / corrections / related issues / comments welcome!

Operations:

Built-in operators:

union |: allow either of two types. also helps get the more lenient of two types, i.e. T | never -> T. you'll encounter this in type inference since optional params yield | undefined types. no known warts.
intersection &: get the stricter of two types, i.e. T & never -> never. shouldn't need this very often. also helps combine two objects. warts:
- overlapping keys when combining objects will & their contents too (alt: Overwrite / MergeAll)
keyof: create a union of string literals from a type's keys. warts:
- returning a string union means number literal keys get converted to string literals
- returning a string union means symbol keys get ignored
- when a string index is present, there is no known way to get the individual string keys
- somehow also gives prototype keys for array types, yet not for object types
in: construct an object type based on a union of strings (keys) and corresponding calculated values based on these. warts:
- since this is based on strings, anything else, such as numbers, symbols, or indices, needs to be specified separately (-> &).
member access: get the type at a certain index of an object/tuple type (considering intersections as a single object, getting multiple result for union'd objects). warts:
- there is ambiguity w.r.t. whether the prototype or the index should trump. it currently lets the prototype trump, even if you wanted it not to, meaning you're likely to get unexpected behavior for member access operations for e.g. toString.
- does implicit conversion between numeric literals and string literals, not unlike JS. not a problem though. :)

& is a bit less straight-forward from the rest in its use-cases:

a way to make impossible types like string & number (uses?)
a redundant way to write never (T & never), which gets more useful given conditionals, but then you could just use those to conditionally produce never right away
a poor man's Overwrite / MergeAll (inferior in its behavior intersecting types in overlapping keys, which poorly reflects actual JS). if you know keys won't overlap though, it's great since it's short, built-in and performant.
'get the most specific type of these two': haven't found use-cases for this, but could also be done given Matches
add a symbol to an existing object
have an index type with keys not bound to sub-classing it

Boolean operations:

Not, And, Or, Eq, Neq

Note: these can currently be implemented through string literal representations. It would be possible to convert these to boolean literals (StringToBool), but cannot yet map boolean literals to these (BoolToString) or other values for that matter.

Array (tuple) operations

Unary:

TupleLength: check the length of a given tuple type.
ArrayProp: get the element type for a homogeneous array type (similar for extracting generics from other parameterized types)

Binary:

~~[x] TupleProp: get the type at a certain index for a tuple/array type. just T[I].~~
TupleHasIndex: check whether a tuple type contains a given index.
TupleHasElem: check whether a tuple type contains a given type among its elements. This could be done given TypesEq.
concatenate / append / prepend. possible today using numeric objects (compatible with ArrayLike), but could become possible for tuple types natively with the variadic kinds proposal at #5453. ~~There has been talk there this would also depend on #6229.~~
destructuring tuples: see above
difference: remove indices in one tuple type from another tuple type. see above.
Vector: create a tuple type for a given element type plus size.

Advanced:

array iteration, used for e.g. TupleLength
reduce: the function needs ReturnType for its dynamic reducer functions; otherwise doable using iteration. see #12512.
map over tuples: doable now through numerical objects for fixed conditions; also needs ReturnType in case the mapping function is given as a function (e.g. map itself).

object operations

Unary:

ObjectLength: check the length (number of keys) of a given heterogeneous object type. doable given UnionLength or (object iteration + Inc).

Binary:

Advanced:

map over heterogeneous objects: probably just needs ReturnType.
object iteration: useful for e.g. ObjectToArray. This could enable union iteration, or the other way around.
- One strategy that comes to mind relies on converting keys to tuple (given UnionToArray) then using array iteration.
- Alternatively, break string literals into characters, convert to numbers, convert objects to a nested version with one key at each stage using key sort, which could then be traversed in order... Nope, no member access on string literals.

Type operations

Type checks (binary):

Matches: check whether a given type matches another type (inclusive, e.g. true for string and string). This could be done given ReturnType.
TypesEq: check whether two types are 'equal', that is, A satisfies B and vice versa. This could be done given Matches.
InstanceOf: check whether a given type represents a subset of another type (-> exclusive match). This could be done given Matches.
PrototypeOf: get the prototype (-> methods) of a type. Partial helps, though Symbol-based keys get killed.

Type casts (unary):

Union operations

Unary:

a way to access union elements, e.g. going from "a" | "b" | "c" to "a". this could enable union iteration using Diff if they're all string literals, which in turn could enable object iteration. or the other way around.
IsUnionType -- solvable today only for unions consisting of known sets of keys, see my Indeterminate; a proper solution could be made using union iteration or a way to access arbitrary / random elements (e.g. with conversion to tuple type)
UnionLength: check the length of a union, i.e. how many options it is composed of.

Binary:

union: A | B
UnionHasKey: check whether a union of string literals contains a given key.
UnionHasType: general case, check whether a union of arbitrary types contains a given type.
- could be achieved using TypesEq. plugging a union into it should return e.g. "0" | "1" in case it contains a match -- at that point UnionHasKey works.
IntersectionUnions: get the intersection of two union types, possible today given unions of string literals.
DifferenceUnions: subtract any keys from one union from those contained in another union.
UnionContained: verify whether one union is fully contained in another.

Advanced:

union iteration: helps implement UnionToArray, IsUnionType. could be achieved given UnionToArray or a way to access elements from a union. This could enable object iteration, or the other way around.

intersection operations

function/parameter operations

ReturnType: get the return type of function expressions -- #6606 (dupes: #4233, #6239, #16372)
conversion of parameters from/to tuple types: see variadic kinds at #5453
function composition -- still issues with generics, see #9366. current approach relies on overloads; might be alleviated as part of variadic kinds, see above.
currying: see function composition.
conditionally throwing 'custom' errors: given ReturnType, apply a function with arguments that would not match its requested param types
pattern matching: given ReturnType, use overloaded type-level function application to emulate pattern matching from other languages.
constraints: e.g. divisor of a division function may not be 0. given pattern matching (above), just add an extra generic to said division function using a default with pattern matching to only resolve for non-0 input, e.g. function div<B extends number, NotZero = { (v: '1') => 'whatever'; }({ (v: 0) => '0'; (v: number) => '1'; }(B))>(a: number, b: B).

operations on primitives (string/number/boolean literals)

These are currently considered out of scope, see #15645.

That said we can do a bit with natural numbers:

Numbers: Inc, Dec, Add, Subtract, Mult, Pow, DivFloor, Modulo, comparators: Gt (>), Lt (<), Gte (>=), Lte (<=)

Strings:

member access on string literals
appending string literals

Progress:

Type	Member Access	Manipulation	Iteration
Tuple	⭕	⭕ (as numerical objects until #5453)	⭕
Object	⭕	⭕	❌
Union (of string literals*)	❌	⭕	❌
Function	❌ (#6606)	❌ (#5453)	n/a
Bool	n/a	⭕ (as strings)	n/a
Number	n/a	⭕ (low-ish natural numbers)	n/a
String	❌	❌ (#15645)	n/a

*: union operators are pretty much limited to unions of string literals as it stands, as the only basic operators on unions (in + member access) both operate exclusively on these.

Not listed: type-level type checks (also need #6606)

Top features needed:

#17961 type level function application, needed for BoolToString, map over tuples / heterogeneous objects, FilterObject, reduce, function composition
#17471 overload resolution / evaluation order issue: make chooseOverload consider type parameter values, not just their constraints. needed for: ReturnType, Matches / TypesEq / InstanceOf, ObjectHasElem, TupleHasElem, throwing errors, pattern matching, constraints, ObjectHasNumberIndex.
#17884 [...a] (tuple manipulation): can be emulated with numerical objects, but they lack methods.
#17898 (...args: Args) => (capturing params)
#18007 Fn(...Args) - relevant for e.g. composition, curry and bind.
#18004 spread tuples
... from union into tuple: casting union/object to tuple. note this one is tougher in that order is technically undefined. Challenges this would address include UnionLength, ObjectLength, UnionHasType, UnionToArray, ObjectNumberKeys, union member access, and ObjectToArray. this last one helps type e.g. R.toPairs; the current compromise alternative Array<a|b|c> there is less useful since it can't be iterated over (for e.g. map).
#17785 - skip automatic type widening for const / params
~~#16072 - generics erased~~

Answer 1 · 2017-06-09T11:46:33.000Z

There are several dead links: #12215(x2), #13470, #16114, their /issues/ are missing.

Answer 2 · 2017-06-09T14:18:12.000Z

@ikatyang fixed them, thanks!

Answer 3 · 2017-06-30T17:59:28.000Z

Update: I fleshed out operations on number literals (if restricted to whitelisted natural numbers), and realized that, although we can't really manipulate tuple types without ... operator, we can actually iterate over these to reconstruct them as numerical objects satisfying the ArrayLike interface (numbers + length), which could suffice as a workaround to operate on 'tuples' for now.

The implication here is that the vast majority of the remaining unresolved challenges now suddenly hinge on a single outstanding feature request (#6606).

Answer 4 · 2017-08-02T07:33:55.000Z

As Playground became less suitable as things grew, I now moved the types into a repo.

Answer 5 · 2017-08-03T06:06:01.000Z

Stellar work. I'm going to pour over this when I get home tonight. Maybe we should turn this into a test suite too and get it accepted into Typescript, so there's no regressions?

Answer 6 · 2017-08-03T06:22:14.000Z

@SimonMeskens: I'd certainly love to improve lib.d.ts, though an official blessing might be more justifiable for types that could already be used to help type it than for the ones that have yet to be applied there. I investigated opportunities to improve it earlier, but haven't found many that'd work out today yet. Specifically:

much of the iteration becomes more useful when we can do stuff with function parameters (#6606) to improve e.g. reduce, filter, and tuple-based map
~~Overwrite does not yet suffice to tackle Object.assign as (mutation aside) variadic functions need #5453.~~ edit: moreover, they recently added syntax that does this too.
if tuples were granted their own interfaces, iteration might already help the likes of concat there, yet though iterations works in types, it still magically breaks when used in functions (#17086)
as noted in #17456, some of the basic building blocks like ObjectHasKey still suffer from some bugs as wel

tl;dr: hopefully, but things might not be mature enough yet.

That said I did see two types failing I'd sworn worked before, specifically Indeterminate and Ramda attempt PathOrFn. I might need to look into those again.

Answer 7 · 2017-08-04T00:24:40.000Z

It feels like we should be able to do ReturnType right now. What's stopping us?

Answer 8 · 2017-08-04T04:38:20.000Z

@SimonMeskens: try it!

interface MyFn {
  (s: string): string;
  (b: boolean): boolean;
}
// ^ example of a problematic function: overloads. similar for generics.
type Ret<F extends (...args: any[]) => R, R> = R;
type Bar = Ret<MyFn>;
// ^ error: Generic type 'Ret' requires 2 type argument(s).
declare function ret<R>(f: (...args: any[]) => R): R;
let baz = ret(null! as MyFn);
// ^ expression level, can't be composed into bigger types
// -> boolean. other option got ignored?

In function declarations, we can do an easy version naively extracting a return type, see the snippet below; a type-level-only version fails meaning we can't really put this to use in other types.
It also fails if the function's return type depended on generics, overloads, or this binding types.
There are a dozen use-cases that depend on the ability to calculate a return type appropriate for given inputs though, which is a topic that could be resolved with that 6606.

Answer 9 · 2017-08-04T10:37:35.000Z

Ah yes, it's basically the issue I talked about on the dynamic function type issue. You can create such a function (well, once 2.5 lands to fix a few of the mapped type bugs), but I don't think TypeScript could ever support complex functions (generics, overloads, not sure about this bindings, you can probably support those eventually) dynamically. You could specifically write a return type construct as in 6606 of course, but the general case is probably not possible, due to the way generics are constructed.

Answer 10 · 2017-08-04T15:29:03.000Z

You can create such a function (well, once 2.5 lands to fix a few of the mapped type bugs)

Could you show a snippet of how you'd go about it with that?

but I don't think TypeScript could ever support complex functions (generics, overloads, not sure about this bindings, you can probably support those eventually) dynamically.
You could specifically write a return type construct as in 6606 of course, but the general case is probably not possible, due to the way generics are constructed.

If you mean the awkward Ret attempt in that snippet, yeah.
If you mean 6606, it already calculates types of return values based on all of that for function calls made on the expression level. It's just about getting that existing operator (() / <>()) exposed in type land.

Answer 11 · 2017-08-04T16:53:16.000Z

Could you show a snippet of how you'd go about it with that?

Not really, because I ran into several bugs trying to make it. The basic idea is that you specify arity by hand and the compiler will complain if the arity is incorrect. Unless we get some way to pattern match types, we can't make the compiler infer arity unfortunately. The arity can be somewhat inferred through a number of overloads at call-site.

Once 2.5 lands, I'll try to produce this type.

I'm somewhat skeptical of 6606, because if it would actually provide a fully working return type, it would be more powerful than Haskell's compiler, if I understand correctly, and I simply don't see how Typescript's generic system would give rise to such a construct. I just returned from a vacation, so my brain is currently too fried to provide an example, I'll try to do so later.

Answer 12 · 2017-08-05T06:19:11.000Z

@SimonMeskens:

If you want you can try 2.5 nightly outside of playground. Heck, even if the code doesn't work yet, the concepts would still be interesting anyway. We'd have progress even if just for arity 0 it works purely on the type level.
On another note, alternatives would be reminiscent of #14400.
Arity I guess could be addressed by either 5453 (capturing variadics) or 6606 (overloads) itself.

I'm somewhat skeptical of 6606, because if it would actually provide a fully working return type, it would be more powerful than Haskell's compiler, if I understand correctly, and I simply don't see how Typescript's generic system would give rise to such a construct.

TypeScript has been doing type literal computations that Haskell never bothered with, e.g. property access on tuples / heterogeneous objects using number / string literals. Ditto for boolean literals, see the type guards in the tutorial.
Note that none of that required generics in the first place.

I'd asked a few Haskell friends this same question before, and their response was just kinda that it wouldn't have as much use for it, in the sense its tuples lacked number-based access, and that heterogeneous objects with string index access basically also lacked a Haskell equivalent.

Answer 13 · 2017-08-05T13:53:43.000Z

I see your point now, you want to be able to infer the return type, not just typecheck it. I don't think that's possible without something like #14400.

Honestly, I feel like not having #14400 is holding the language back. That's probably my number one feature request, more inference on generic arguments.

Answer 14 · 2017-08-05T14:07:07.000Z

Well, #14400 itself wouldn't address overloads/generics or the like, while we can already get the return type like that in function definitions already (ret example above). In that sense it'd be a relatively smaller step. If we could get 6606 then from what I can see that'd cover it.
Then again I also just don't know how implementing 14400 would actually work.

Answer 15 · 2017-08-05T14:10:36.000Z

#14400 Already exists in C# and many other, simpler languages. It's a small subset of what you want to cover with 6606. On the other hand, 14400 opens up a bunch of doors all over the place, not just for return types.

Answer 16 · 2017-08-05T14:12:12.000Z

Alright, fair enough.

…

On Sat, Aug 5, 2017 at 10:11 PM, Simon Meskens ***@***.***> wrote: #14400 <#14400> Already exists in C# and many other, simpler languages. It's a small subset of what you want to cover with 6606. On the other hand, 14400 opens up a bunch of doors all over the place, not just for return types. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#16392 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC6uxfISBevyZFa_qkKRGGfsiAC9G8Ngks5sVHf_gaJpZM4N1Jex> .

Answer 17 · 2017-08-06T03:40:15.000Z

I've just posted a suggestion for type declaration overloading at #17636. @tycho01, I wonder if you'd like to have a look and see how useful you think that might be to realising some of the stuff in this issue? I'll take more of a look myself when I have the time, but I'm pretty sure @17636 would open up BoolToString at least, maybe many more.

Answer 18 · 2017-08-06T04:39:27.000Z

@TheOtherSamP:

Going by my list in 6606:

overloading covers:

operate on boolean literals
unwrapping like promised
constraints, incl. (non-) union
type subtraction
type checking
checking index presence

not covered is function application:

angular factories
higher-order functions (compose, curry, bind, reduce, filter, tuple map, ...)
lenses

Going by my list here:

type manipulation: ReturnType, BoolToString, Matches / TypesEq / InstanceOf, ObjectHasElem, TupleHasElem, conditional errors, pattern matching, constraints, ObjectHasStringIndex, ObjectHasNumberIndex.
function stuff: map over tuples / heterogeneous objects, reduce, filtering objects by predicate

tl;dr:

when we do actually need to do stuff with functions (because we get them in through params) we would, for better inference, need a way to deal with those.
for every other use-case you'd be correct I just brought in functions to address this overloading, and that an alternate method of doing overloads could also cover that.

Edit: one potential con of your type overloading approach is that it may require adding external types, while a function approach might also allow anonymous functions. From what I can see this should not necessarily be a deal-breaker for any of its use-cases though.

Answer 19 · 2017-08-06T04:47:53.000Z

@tycho01 That's great, thanks! That's a big list of stuff that works. Honestly, even when we get #6606 I still think it would be nice to have both. Type declaration overloads seem neater for these things, having to bring functions into those operations feels like a bit of a hack. I think I'd be in favour of having both features in the language alongside each other.

Would you mind copying that list over to #17636? I think you've made a pretty decent argument in favour of it being worth considering there, far more exhaustive than mine, it would be nice to have it in that issue. Alternatively I could steal it and edit it into the main post I suppose.

Answer 20 · 2017-08-06T06:19:38.000Z

@TheOtherSamP: I found a few kinks:

Functions can capture inferred types in generics based on provided param types. This is relevant to obtain references for things we cannot otherwise refer to:

parameter / return types of unapplied functions
constituents of unions (/ intersections?)

Examples depending on this:

type subtraction as demonstrated in #17370 (comment)
that type Return = <T extends () => S, S>(f: T) => S; I mentioned in #14400 (comment)*

This could also be tackled through #14400.

* Given 6606 that is not how you wanna calculate return types (doesn't consider param/generic types), but it's a bit of a shorter demo than extracting params of an unapplied function into a tuple type.

There are anonymous functions, yet not (yet) anonymous types. As a result, a 6606-based approach allows type 'currying'.
As an example, type checks with 6606 would use e.g.:

export interface isT<T> {
  (v: T): '1';
  (v: any): '0';
}
export type Matches<V, T> = isT<T>(V);

With #17636 that might look a bit like:

type isT<T, V extends T> = true;
type isT<T, V> = false;

The 6606 approach might allow terse derivatives e.g. type isBool<V> = isT<boolean>, for which 17636 might still need to manually put the overloads in external types.
That's doable for a known type like boolean, but for a type from a generic, externalizing is not possible. I'm not yet confident w.r.t. what use-cases might require that.

tl;dr aside from doing stuff with actual functions, 17636 covers the use-cases of 6606 with a few (fixable) holes, namely capturing inferred types (#14400) and anonymous types (not aware of proposals).

So yeah, I'll post there too. I think I should have the differences down now.

Answer 21 · 2017-08-07T00:27:52.000Z

I'm not sure if this is new, but I found a cool trick that allows some basic type switching (and more cool things) by augmenting some global interfaces. It's a bit hackish, but I think it's okay, I haven't hit any problems with it yet. It also allows the implementation of type DeepReadonly<T> which is awesome, but I'm not yet 100% sure whether that's relying on a bug or not.

Figured it was worth noting here in case it's new and opens up anything else on this list.

I don't know if there's a fancy way to link to gists, but here: https://gist.github.com/TheOtherSamP/ab0c7305d241cee4c7f0452f11a4d1f1

Answer 22 · 2017-08-07T05:23:35.000Z

@TheOtherSamP: so until we can do checks on types, we'd extend them with a string property since we can check those huh. nice idea, I hadn't tried it.
I guess the limitation there is that it can't really make further distinctions, e.g. between booleans.
It'd be interesting if you could use this to e.g. branch to start doing type-specific operations, though I'm not sure the branching will have proven sub-type compliance for the purpose of the compiler.

why is DeepReadonly<T[K]> allowed when T[K] is not guaranteed to be WithTypeInfo?

Maybe related to altering the Object interface, as all in JS should extend that.

There's probably a less verbose way of doing this

I had a StringsEqual in typical that might help there.

Answer 23 · 2017-08-07T05:32:21.000Z

@tycho01

why is DeepReadonly<T[K]> allowed when T[K] is not guaranteed to be WithTypeInfo?

Maybe related to altering the Object interface, as all in JS should extend that.

Maybe, but I've found it oddly inconsistent with when it requires <T extends WithTypeInfo> and when it doesn't. I need to go through it all and tidy things up and see if I can work out what's happening there.

I've actually just updated that gist so DeepReadonly<T> handles arrays nicely. I've done that by adding an extra specific annotation to arrays to retrieve their type. With a bit of fiddling about, I think there might be something in that as far as extending the main inbuilt (Map, Set, ReadonlyArray...) types goes.

Answer 24 · 2017-08-07T05:40:13.000Z

Fortunately JS prototypes don't really seem to have inheritance / hierarchies (do they?), that might've been hard to express here. I guess TS classes / types do though.

Answer 25 · 2017-08-07T05:53:02.000Z

I think where I'm at with understanding this stuff is best explained by the fact I just went to make a little recreation of something confusing that wasn't working before, only to find it seems to work fine now. 😂

Answer 26 · 2017-08-07T05:53:56.000Z

Fortunately JS prototypes don't really seem to have inheritance / hierarchies (do they?)

JavaScript features prototypes, a deconstructed superset of classic object-orientation. It's strictly more expressive, more modular and more expressive. One of the parts is differential inheritance through prototype hierarchies. Luca Cardelli's "a Theory of Objects" goes into detail about these concepts in the opening chapters. It's a good read, but a bit hard to get a hold of cheap.

Eric Elliott explains it specifically for JavaScript here:
https://medium.com/javascript-scene/3-different-kinds-of-prototypal-inheritance-es6-edition-32d777fa16c9

He expands on some of this stuff in his newer series of articles:
https://medium.com/javascript-scene/composing-software-an-introduction-27b72500d6ea

Answer 27 · 2017-08-07T06:00:36.000Z

@SimonMeskens: I hadn't had much knowledge of the underlying background / theory there; thanks! 😅

Answer 28 · 2017-08-07T06:03:27.000Z

@tycho01 Not everything extends from Object within the type system - TypeInfo<undefined> doesn't work. never and any are weird cases too, they don't get the type augmentation, but they compile fine because they can go anywhere.

Answer 29 · 2017-08-07T06:05:33.000Z

@TheOtherSamP: makes sense. In that case I guess your question on why the type-checker was cool with it sounds pretty legitimate.

Answer 30 · 2017-08-07T06:07:37.000Z

@tycho01 Yeah, there actually seems to be a larger issue (though it's useful so far, maybe feature?) with constraints not being checked properly in nested/recursive types. Although now I think about it, I wonder if something is becoming any somewhere along the way in the checks and allowing it.

Answer 31 · 2017-08-07T06:11:47.000Z

Although this toy example to recreate the issue actually does get caught, so whatever that behaviour is is a bit more subtle.

type MustBeNumber<T extends number> = T;
type KeyofWhatever<T> = {[K in keyof T]: MustBeNumber<T[K]>}; // Errors

I'll have to fiddle about and see if I can recreate. I think I also found another bug (something was working inline, but not through a layer of type declaration abstraction) earlier too, but I just went a completely different route around it, so I'll have to see if I can recreate that for bug report.

Answer 32 · 2017-08-07T06:14:14.000Z

@TheOtherSamP: this is one of the things I find tougher about type-level programming; you can't just like cram in some logging statement for debugging... I do wonder how people with more experience like @gcnew are going about that, assuming it doesn't require full familiarity with the compiler so as to run it through that with breakpoints.

Answer 33 · 2017-08-07T06:19:20.000Z

@tycho01 Yeah absolutely, there's a lot of trial-and-error involved in my process here, rapid iteration, and stuff like this sitting around for debug-by-tooltip checking:

type H = DeepReadonlyObject<DummyInterface>;

// type A = HasProperty<{test: 5}, "test">;
type IsArrayTest = IsArray<Array<string>>;

type C<T> = IsArray<T>;
type D = SpecialTypeOf<string>;
type E = HasSpecialType<string[]>;
type F = IsSpecial<string, "array">;
type G = IsArray<string>;
type I = DeepReadonlyArrayUnsafe<string[]>;

I also try to break the bits I'm working on down into as many smaller declarations as possible so I can get in there and test bits individually. Then of course there are those few times when breaking them up (buggily?) changes the result like I hit earlier with this... That's no fun.

Answer 34 · 2017-08-07T06:25:20.000Z

@TheOtherSamP Do you know about these two issues?

#17455
#17521

It sounds like you're running into these bugs maybe.

Answer 35 · 2017-08-07T06:31:41.000Z

Oh, good find @SimonMeskens! It's hard to know if those are the exact issues I'm running into, but they're (the second particularly) definitely highlighting problems in the same area I'm dealing with, looks like a good fit.

I'm a little worried that the recursive stuff in my DeepReadonly<T> is going to break when those get fixed. I'm not really doing anything too hacky in the recursion itself though, so if it does break I think it means we may have a further problem with how recursion is currently designed. Although actually... I think that would be fixed by #17636.

Answer 36 · 2017-08-07T06:35:43.000Z

I stuck my gist into the playground with a little test right at the bottom, if anyone wants to play with DeepReadonly<T> as it stands it's here.

Answer 37 · 2017-08-07T06:39:52.000Z

types C ~ I

@TheOtherSamP: yeah, my gist got full of things like that until I recently turned them into 'tests' to publish as repo.

Answer 38 · 2017-08-07T06:45:59.000Z

@tycho01: Smart. Yeah, at this rate I'm having enough fun playing about that I might start putting together my own rival type library like yours. Not actually to compete, but it might be interesting to see if there are things we come up with different approaches to.

I also have the sudden urge to try to leverage the compiler into integrating type based tests into existing testing tools... No idea if that's even possible, and it's probably insane, but it might be fun. I'll add it to my list.

Answer 39 · 2017-08-07T06:50:16.000Z

@TheOtherSamP: feel free to check how I'm doing the tests now, basically expressions asserting type outcomes that'll give compiler errors if they don't match (<=). So I 'run tests' just by compiling spec files. I just now ran that through tee to add error output to version control as well. That way Git GUIs will just visually show changes in errors.

Answer 40 · 2017-08-07T06:53:41.000Z

@tycho01 That's way more sane that what I'm probably going to waste a load of time trying before finally admitting that your way was best all along.

Answer 41 · 2017-08-07T06:59:24.000Z

@TheOtherSamP @tycho01 I'm using typings-checker, you can define positive and negative assertions about TypeScript types and errors https://github.com/gcanti/typelevel-ts/blob/adfce078f96d0491dc5736a23a459330f2e8d579/typings-checker/index.ts#L87

Answer 42 · 2017-08-07T07:07:58.000Z

@gcanti Oh wow, that looks fantastic, thanks for that link! Maybe not quite suited to the rapid iteration during prototyping, but great for marking things down once we've got them wrangled a bit. That was basically what I was going to try to make anyway, so that's saved me a lot of wasted time. 😅

Answer 43 · 2017-08-07T07:12:31.000Z

@TheOtherSamP:

I loved PlayGround as well, and regressions weren't much of an initial concern; I was just forced to convert it as eventually a few types snuck in that had terrible performance / did not terminate.
I wanted to just comment half the types to find them binary search style, but the types depended on each other in many directions and finding the culprit was terrible.
My current situation slightly improved over that by allowing an attempt to compile one file (+ all deps) at a time.

@gcanti:

Fair enough, that does look like a potential improvement in the face of expected errors. On actual failed expectations, I recall I had a fork of it ditching line numbers from output so diff logs wouldn't get noise from line number changes, might have use for that here too. Guess I specialize in libraries that error.

I hated having to give every test line a name btw 😅, fortunately that's separate.

Seems unlike me you're also using value level expressions in your tests. That's interesting to me; I'd kept it type-level only. I don't even have any real considerations there, just sorta happened.

Answer 44 · 2017-10-06T13:52:35.000Z

@tycho01 When you say

keyof: create a union of string literals from a type's keys. warts:

indices (whether number or string) get ignored

What do you mean by "ignored"? Note that keyof { foo: number; [k: string]: any } returns string, not "foo". Is that what you mean (I would call this the opposite of being ignored, myself) or did this behavior change? I do wish there were a way to get just the non-index keys from a type... is that a type operator I missed from your list?

Answer 45 · 2017-10-06T14:04:59.000Z

@jcalz: sorry, lemme fix that, looks like I was mistaken there!
That actually seems a bit unfortunate though, guess that means it's hard to operate on constructs like that in such a way as to retain the key-specific info...

or did this behavior change?

Could be, but for all I know I just messed up there somehow. :)

I do wish there were a way to get just the non-index keys from a type... is that a type operator I missed from your list?

Hm.... before I thought that e.g. Omit would lose the indices while retaining the keys. In that case that might have been a way. Otherwise, it's gonna be tough.

This did just helped me think of an implementation for ObjectHasStringIndex though!

Answer 46 · 2017-10-25T15:04:40.000Z

Marking as closed since a discussion doesn't require moderator attention.

Answer 47 · 2018-02-15T19:51:51.000Z

@jcalz @MartinJohns here is fine to me.
I tried for a bit to see if I could strip the index off an object type, but haven't managed yet.
on a related note, ObjectHasStringIndex works, but isn't helping here.

I guess if we had a keyof equivalent not screwed up by the string index, that should get us there. It seems pretty tough though. So the real keyof would yield e.g. "a" | string, which just simplifies to string, removing all the info we were actually interested in.

So the more realistic approach seems to be to use a filtered map instead. My attempt has been among the following lines:

type T = { a: 1, [k: string]: number };
type stripped = { [P in keyof T]: string extends P ? never : T[P] }; // want { a: 1 }, got { [x: string]: string }

Not sure why it fails. :(

Answer 48 · 2018-02-15T20:21:00.000Z

Yeah that's about as far as I got too.

Answer 49 · 2018-02-17T13:40:14.000Z

@jcalz @MartinJohns in retrospect, guess it fails because it still relies on keyof... which means back to square 1. :(

Answer 50 · 2018-04-23T18:02:36.000Z

Looks like IsUnionType<T> can now be implemented using distributive conditional types, even for T that do not extend string:

type IsUnionType<T, Y=true, N=false> =
  [T] extends [infer U] ? U extends any ? [T] extends [U] ? N : Y : never : never

This exposes some fun details of what the compiler considers a union:

const literalsGetAbsorbed : IsUnionType<string | 'a'> = false;
const booleansGetDistributed: IsUnionType<boolean> = true;
const intersectionsOfUnionsAreReduced: IsUnionType<{a: 0} & ({b: 1} | {c: 2})> = true;

Answer 51 · 2018-04-23T19:01:47.000Z

@tycho01 Are you still looking for a way to strip indexes? I have a way to do it

Answer 52 · 2018-04-23T19:16:03.000Z

Actually, my way of doing it corresponds to your last attempt up above, which now seems to work, so you should be golden.

Answer 53 · 2018-04-24T13:17:27.000Z

Doesn't that still give you type stripped = { [x: string]: never; a: 1 } instead of the desired { a: 1 }? How do you use that to strip the index?

Answer 54 · 2018-04-24T15:21:08.000Z

Yeah, totally my bad. I thought I had discovered some new trick, when I didn't. I figured out most of the issues people were having as I bashed my head against it for an hour yesterday.