However, more than once I've also yelled "HOW DO YOU NOT KNOW THIS?!" at something or other :)

Just today I was triggered that this compiles.

declare foo: never[] // it can only be an empty array

foo[1] // compiles

TypeScript is a nice type system, it's surprisingly expressive and flexible, like e.g. in Haskell I was surprised that there's this strange notion that for a given type you can only have one `Eq` or `Ord` instance for some type A.

But in TypeScript you can have as many Ord interfaces as you want. I may want to order some `User` type by last login, first login or whatever I want, but in Haskell you need to overcomplicate it and create a newtype.

> you can only have one `Eq` or `Ord` instance for some type A.

This is a good thing - it stops you from using one Ord instance when putting As into a Map or Set, and then trying to pull them back out using another. Newtypes let you provide "additional" instances in a safe way.

Why shouldn't I be able to use as many Ord instances as I want?

I'll give you a trivial example I have some data type representing a TvShow, why should there be just one way to sort a collection of TvShow? Maybe I want to sort by year, maybe by length, maybe by category.

It's trivial to do in fp-ts, you can have as many Ord instances as you wish.

Ord is for the natural (obvious and hopefully uncontroversial) ordering of a given type.

If your type doesn't have a natural ordering (as your TvShow doesn't) then you would use sortBy to supply an arbitrary compare function (just like what you would define in your Ord instance).

You seem to be a bit confused because indeed there's no such thing as "natural, uncontroversial, obvious ordering".

Ordering (and more specifically a total ordering) in mathematics is a set and a binary relation that has the transitive, irreflexive and connected properties.

Not even natural numbers have "uncontroversial natural ordering", as I guess even you can think of at least two different binary relations (<= and >=) that form two different orderings for N.

There's a lot of orderings more, here's one that sorts first odd and even numbers: "0 < 2 < 4 < 6 < ... < 1 < 3 < 5 < 7 < ...". And there's others like this.

https://en.wikipedia.org/wiki/Gray_code

Natural numbers in fact have (or better: form) an aleph one types of orderings. None is "special, uncontroversial or natural" just because we're used to think about the default <=.

The concept of ordering requires two things: the data type and the binary relation. It's a pair of things we can represent as (X, compare) but which compare you choose isn't implicit, natural or magical.

When talking about Haskell, it has the concept of type classes, where types and their behavior are bundled together. That's a design choice of Haskell which has pros and cons, but there's no mathematical foundation for a data type to have one preferred ordering.

Ocaml, Scala and most pure fp libraries I know do not have the limitations of Haskell when it comes to the concepts of ordering and equality, in fact in most of those when asking for an ordering ask you for a data type and a compare function. Exactly what the mathematical definition requires you to.

Not a typeclass where those are bundled together for some design decision.

Hope I clarified you that there's no such thing as "uncontroversial natural obvious" ordering, because there's no such things in mathematics.

the argument is that usually you do not want that, it is a Haskell typeclasses vs ocaml modules discussion

They just said why it's important to explicitly track which instance is in effect and newtypes do that.

I wouldn't expect never[] to mean 0 length array, tbf. It's a variable length array of _type_ never. It should be something akin to:

    declare foo: never[0];

I think the correct solution is:

    declare foo: []; // fixed-length array (tuple) without any items

JS is a strict language, so an array containing one or more bottoms is a bottom. The only legal value is the empty array, at least in theory.

foo[1] is undefined (literally the undefined symbol), in JavaScript index-out-of-bounds is ok.

Although i don’t know if TypeScript asserts that x[i] is T | undefined if x is T[] and the length is non-trivial. In strict mode this would be really useful as you can just do x[i]!, but it requires you to think a bit about index-out-of-bounds or at least throw on the undefined case.

> i don’t know if TypeScript asserts that x[i] is T | undefined if x is T[] and the length is non-trivial

There's a flag for that: https://www.typescriptlang.org/tsconfig#noUncheckedIndexedAc...

Just a note that TypeScripts type checking & compilation are two separate systems. It's never a compilation error because it always compiles.

In TS this is controllable. If noEmitOnError is true, then any error (including type errors) will stop it emitting JS output.

I believe the type you're looking for is `[]` (a tuple with no elements) instead of `never[]`.

https://www.typescriptlang.org/play?#code/CYUwxgNghgTiAEYD2A...

Yes I know, but `never[]` should also be unaccessible by index since it can never have any value.

variable length arrays are accessible at all indexes,

const a = foo[1]

should result in a bring of type `never|undefined` or `undefined` depending on flow analysis

> But in TypeScript you can have as many Ord interfaces as you want. I may want to order some `User` type by last login, first login or whatever I want, but in Haskell you need to overcomplicate it and create a newtype.

I don't think that's accurate. Typescript only has one instance of Ord per type and it's inconveniently implemented through the method toString.

To usefully sort anything other than strings in Typescript, you are using a function where you provide your own comparator at runtime. That's more analogous to Haskell's `sortBy :: (a -> a -> Ordering) -> [a] -> [a]` or `sortOn :: Ord b => (a -> b) -> [a] -> [a]` which don't put any type bounds on the type you're sorting.

I've managed to get the compiler to typecheck

  const x: Thing = exprA;
  const y: Thing = exprB;
  const z = [x, y];

but somehow not:

  const z: Thing[] = [exprA, exprB];

although exprA and exprB were pretty nasty typing wise.

> but somehow not: const z: Thing[] = [exprA, exprB];

Doesn't

    const z = [exprA, exprB] as const;
    type GnarlyThingTuple = typeof z;

or something like this help?

Where you trying to create a tuple? Does `const z: [Thing, Thing] = [exprA, exprB];` work?

I'm the opposite. I was continually perplexed by trivial stuff that TypeScript just couldn't figure put. Maybe that has changed in the last year but I doubt it.

In my 5+ years introducing TypeScript everywhere that my team has to use JavaScript, this is almost always because JavaScript is an insane language that allows many counterintuitive things.

TS is sometimes weird because it is a superset of JS and has to be compatible.

Do you have examples?