Weird - using constant string discriminators feel very natural and normal to me in Typescript. What do other languages do without them?

Most model it as an actual enum, if backed by strings. Typescript, by comparison, requires being able to indicate a type just from a string argument

Allowing literal strings and type aliases of unions of strings to represent enums doesn't seem unreasonable. It's the same concept as many other languages with some extra quotes, ex. https://ocaml.org/docs/data-types#a-simple-custom-type

"Some extra quotes" make a big difference though. The type of

   Red

in OCaml is pretty unambiguous, but the type of

   "Red"

in Typescript is not. The typesystem has to do a lot of work to support strings as both enum values, type descriptors and characters-strings.

This doesn’t change anything:

  foo(get_some_myenum_value(), …)
  {type:get_another(), …}

These are as unguessable as if myenum was a string.

Hmm. That doesn't feel like much of a difference to me?

It's huge? I'm really confused lol. I write in Dart/Java/C++/ObjC/TS regularly to maintain a cross-platform library and this is a massive difference from every typechecker in any other language, much less the narrower thing of if the idea of reifying random strings into an enum is a novel feature. I get a very strong sense from the thread that people are talking past eachother, somehow.

The event type could just be exposed as a regular property so you could write `element.onclick.add((ev => ...)` so you would get static typing without any need for magic strings.

Magic string are use all over JavaScript for different purposes. For example createElement('P') could just be new PHtmlElement() ...

In other cases magic strings could be replaced with enums.

Changing Javascript is explicitly out of scope for Typescript.

I was curious how other languages did discriminators in a way that makes Typescript's feel alien. Just having different functions doesn't really tackle that.

Agreed and I think the reason for this confusion is because string types generally aren't considered a complicated feature of typescript.

Nor is it unique to it. I.e. elexir does the same through pattern matching and it works even better as far as I'm concerned.

It's more about the features that enable extended type inference and modifying these inferred types on-the-fly.

Easy to understand type modifiers like Omit<>, Partial<> etc are fine, but if you lean into that you can create pretty hard to understand typing logic. Especially if you're diving into annotations for code generation

The pattern I'm most familiar with is using type constructors:

   type Shape = Square Int | Circle Int

and then pattern matching:

   print (Square size) = ..
   print (Circle radius) = ...

In Typescript this would be something like:

   type Shape = { type: 'square', size: number } | { type: 'circle', radius: number }

And string matching for type narrowing:

   function print(shape: Shape) {
     if (shape.type === 'square) {
       ...
     } else if (shape.type === 'square) {
      ...
     }
   }

The TypeScript approach is comparatively weird and verbose but also pretty clever since it doesn't require any change to the core language.

It also have some pitfalls, e.g. you can write:

  print({type: 'square', size: 10});

But you cant write:

  const x = {type: 'square', size: 10};
  print(x); <-- type error

You have to write:

  const x = {type: 'square' as const, size: 10};
  print(x);

Things like this just complicates the type system and type inference.

This example looks like a simple sum type with method overload. Don't think that's complex, that's bread and butter in some functional languages.

Now take mapped types, template literal types, key remapping... Those features aren't necessary to express legacy DOM APIs, this is just for the sake of having a complex typing system. And that's not to add a new feature that unlocks some type magic that wasn't possible before. No, those are just shorthands for things that you could already express in the existing typing system.

It is not just to support the DOM it is also frameworks like JQuery, React, Vue etc.

For example the 'options' parameter is a common pattern where an object with a set of properties are provided to override a some default behavior. So you need to define a Foo type with a set of properties, and then you need to define a type which is like Foo except all properties are optional.

Some frameworks implement their own flavor of inheritance e.g. through mixins. The type of an object with mixins is not just the sum of all properties, you might also have one property overriding a property of a different type in base mixin, so you are adding and removing properties. You need a really powerful type system to be able to represent this.