Support non-structural (nominal) type matching

[fgodino]

Feature Request

Hi! First of all, congratulations on this project. It's amazingly well structured.

I started using it for one of my projects where I use Nominal typing (aka branded typing). Since typescript is structural, I am mimicking it using an intersection of primitive type and object (See https://twitter.com/mattpocockuk/status/1625173884885401600?lang=es). For example:

type UserId = string & { __brand: 'UserId' };
const userId = '11' as UserId;

There are other ways though, to approach this. https://michalzalecki.com/nominal-typing-in-typescript/

The problem

The problem I am having is that when I try to use typia to compile the above example, I am getting a nonsensible intersection error.

Would it be possible to have some "special" Nominal type like typia.Nominal<T extends string | number> that allows for this kind of behavior.

Approach ideas

I am thinking the metadata constructors could identify this special case (using unique symbols as the object maybe for more safety):

declare const brand: unique symbol;
type Brand<T, TBrand extends string> = T & {
  [brand]: TBrand;
};

I think Branded types are a very common artifact in a lot of repositories and it's worth exploring it.

Let me know what do you think and if can be of any help.

Edit: I don't think this should affect validation at runtime (if the Nominal type extends primitive string, the validation should check that the input is a string).

[samchon]

Duplicated issue - #911

As you know, typia is using the pure TypeScript type directly instead of defining extra schema.

Therefore, it is not possible to support the prohibited feature in the TypeScript like this one. The branded type must not harm the TypeScript type, and have not to occur the compilation error, either. If you still want to utilize the branded type without the compilation error, make the property type to be optional. Then no problem would be happened.

import typia from "typia";

interface Branded {
  something: string & { brand?: number };
}

const branded: Branded = {
  something: "nothing",
};
typia.is(branded);

https://typia.io/playground/?script=JYWwDg9gTgLgBDAnmYBDOAzKERwERIqp4DcAUGcAHYwCmUGqAxrXAEJSpUAmt3cAbzJw4AZxy0YAC2oBzAFxiYUOXABkguACNOPAPyKqAVxBb6cAL7kLFJhCqj4Orr26KOLvnAC8g4WIlpOUU8Kgggqlk8ABoyKzJCNAA6YFEACmcePgBKcjIgA

[fgodino]

I understand the issue but what about casting?

If you cast the string to BrandUser then the ts compiler works just fine

import typia from "typia";

type BrandUser = string & { brand: 'user' };

interface Branded {
  something: BrandUser
}

const branded: Branded = {
  something: "nothing" as BrandUser,
};

Besides, if I make the brand property optional then the type renders useless:

type BrandTeam = string & { brand?: 'team' };
const teamFunction = (type: BrandTeam) => {}
teamFunction('notATeam') // This should throw an error but it doesn't because of the optional property

[samchon]

Don't suggest me non-standard feature violating the main principle of TS please.

If you want to enhance the type checking through the classification, just define like below. It is much safer than the brand type.

interface PasswordInput {
  type: "password";
  value: string;
}

[MatAtBread]

There's a long discussion of this and a related issue (boxing of primitives by Object(...),Object.assign(...) and new Object(...)) in #911.

I've forked and added a typia.tag to permit this usage - please read the above thread and see #911 (comment) if you wish to use "branding" with typia.