Write a function to define types.

Search Terms

type defination, functional type defination, meta, meta programming, dynamic type declaration

Suggestion

Write a function to define types.

Use Cases

Build a more complex type.

Examples

type MyType<T extends string>{
  if(T extends 'a'){
    return 'a' //type 'a'
  }
  if(T extends 'b'){
    return 'b' //type 'b'
  }
  return string
}

Checklist

My suggestion meets these guidelines:

• [x ] This wouldn’t be a breaking change in existing TypeScript/JavaScript code
• [x ] This wouldn’t change the runtime behavior of existing JavaScript code
• [x ] This could be implemented without emitting different JS based on the types of the expressions
• [x ] This isn’t a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• [x ] This feature would agree with the rest of TypeScript’s Design Goals.

[mindplay-dk]

Someone recently posted a “mental model of TS types” on Twitter - this tries to relate the declarative type expression syntax to imperative code, which is what JS developers know.

I think this feature ought to be considered quite seriously. Only a few people ascend to become the rare sort of TypeScript Gurus who can wrangle the type system, which is not only a departure from the syntax of the language it’s building on top of, but also an entirely different language paradigm: essentially a touring-complete functional programming language on top of JS.

It’s more like C++'s meta programming.

It is, but it’s also not.

C++'s meta programming generates code - whereas what’s proposed here generates types only.

Related #39385, where someone suggested evaluating user-code as part of the compilation, to which the TypeScript team responded:

Executing user code during compilation time is the first step toward madness; we don’t implement features like this and don’t intend to.

But they already did.

Someone implemented Worldle using TS types.

Here’s an article explaining how to build tic-tac-toe using TS types.

So it’s already a fully functional programming language for types.

TS type expressions are functions that operate on types.

Is it just asking for a different syntax for existing functionality?

From my perspective, it is.

We’re asking for a syntax that’s more familiar and accessible to JS developers.

I don’t think we’re asking for TS to become a meta-programming language, where you can write JS that actually generates JS - what I have in mind is JS that generates TS types, using a more familiar syntax, and using a paradigm that’s more accessible to JS developers.

I think part of the reason TS divides the community somewhat, is because typing is hard. I have 24 years of experience as a web developer. I have no substantial experience with functional programming languages, I’ve had to work hard on this for years, and I’m still nowhere near grasping more advanced examples like the Wordle and tic-tac-toe examples above.

I still frequently find myself running into problems I just can’t solve - I’ve had to shelve many interesting ideas that were easy to prototype in JS, but despite my best efforts, I could not figure out how to make them type safe. I know many developers in the same boat, and most of them do not go to the lengths I’m willing to go to.

Libraries such as ts-toolbelt has tried to make this more accessible, by implementing many of the core functional primitives as types - and definitely succeeds to some degree. But if you don’t have at least a bit of experience with FP languages, you’re still likely going to feel somewhat lost and overwhelmed by the learning curve here.

That’s why I think this feature is a great idea - possibly the greatest idea ever proposed for TS.

Can you imagine bridging that gap. Shutting down the last legit excuse to write code without types. “Typing is hard”. Yeah, it is. It’s really, really hard. Maybe it’s time to consider a feature that would make it really easy and accessible to Everyone ? 🙂

I think you have a real chance to bridge divide here.

[brillout]

This is especially true for library authors.

As a TypeScript end-user, you can always bail out with any.

But as a library author, you want to provide type safety which more often than not involves very complex types. I’ve already spent a lot of time trying to provide type safety to my users.

This would be a dramatic and foundational change. Digging into this could be tremendously worth it.