Allow to pass "unique symbol" as a type parameter (e.g. Opaque<string, unique symbol>).

[olalonde]

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

I have been trying to write a type helper to facilitate the creation of nominal types (aka branded/tagged/opaque types), but I'm a bit stuck by the fact I can't pass unique symbol as a type parameter.

The following doesn't work:

type Opaque<T, TBrand> = T & {
  readonly __brand: TBrand;
}

type UserId = Opaque<string, unique symbol>;
// error: 'unique symbol' types are not allowed here.
type GroupId = Opaque<string, unique symbol>;
// error: 'unique symbol' types are not allowed here.

function printUserId(userId: UserId) {
  console.log(userId)
}

printUserId("abc" as UserId);
printUserId("def" as GroupId);

And if I just get rid of the TBrand parameter, it considers both UserId and GroupId to be compatible.

type Opaque<T, TBrand> = T & {
  readonly __brand: TBrand;
}

type UserId = Opaque<string>;
type GroupId = Opaque<string>;
// error: 'unique symbol' types are not allowed here.

function printUserId(userId: UserId) {
  console.log(userId)
}

printUserId("abc" as UserId);
printUserId("def" as GroupId); // works ... :(

📃 Motivating Example

See suggestion.

💻 Use Cases

1. What do you want to use this for?

Creating nominal types

2. What shortcomings exist with current approaches?

Have to memorize how to do it, more code to type.

3. What workarounds are you using in the meantime?

To do the nominal type without using a type helper.

[nmain]

You can create each unique symbol.

Or, if you want the symbols to only exist in type space and not at runtime, you can declare each unique symbol.

[fatcerberus]

^^^ what he said. unique symbol types are tied to a variable declaration, to ensure they always have an identity. Otherwise every utterance of unique symbol in the program would create a new type and you’d have no way to refer back to old ones.

[olalonde]

Those are good workarounds but they are workarounds.

unique symbol types are tied to a variable declaration, to ensure they always have an identity.

That's not true. For example:

type UserId =  string & { readonly __brand: unique symbol };

Otherwise every utterance of unique symbol in the program would create a new type and you’d have no way to refer back to old ones.

Not sure what you mean by that.

[fatcerberus]

It means exactly what I said. Your own example is of creating two Opaque<string, unique symbol> and having them be distinct types despite being the exact same in the source text. But if that were allowed, how could you later refer to the unique symbol type for a particular Opaque if you haven’t given it an identity in the program?

[fatcerberus]

Those are good workarounds but they are workarounds.

By this reasoning, what you’re trying to do is a workaround too and you ultimately really want #202. You have to compromise somewhere.

[olalonde]

I am not sure I understand why are you opposed to this feature? Because there are workarounds?

[fatcerberus]

Not opposed per se, just pointing out the opposite: if you’re opposed to being forced to use workarounds, then adding a feature whose only apparent purpose is to make what’s already a hacky workaround for the stated use case easier doesn’t seem like the way to go.

[olalonde]

What seems like the way to go?

[fatcerberus]

#202

[olalonde]

I agree that #202 would be ideal but it has been opened for almost 10 years and it could be opened for another 10 years. While the feature I propose is not be a big change, it's even arguably a bug.

[andrewbranch]

This can’t be done without allowing unique symbol types literally anywhere (and so redesigning the entire feature) since the generic type could use the type anywhere:

type Id<T> = T; // obviously legal type alias declaration
type X1 = unique symbol; // error: 'unique symbol' types are not allowed here
type X2 = Id<unique symbol>; // instantiation is legal but results in the same type as X1, which is illegal?

[typescript-bot]

This issue has been marked as "Working as Intended" and has seen no recent activity. It has been automatically closed for house-keeping purposes.