TypeScript: Branded Types

https://prosopo.io/articles/typescript-branding/

by arbol • 2 years ago

190 203 2 years ago

pprotas• 2 years ago

Amazing, we have invented nominal typing in a structural typing system.

Sometimes I wonder what kind of programs are written using all these complicated TS types. Anecdotally, we use very simple, basic types in our codebase. The need for tricks like this (and other complicated types) is simply not there. Are we doing something wrong?

odyssey7• 2 years ago

Nope, if you have lower expectations for your type system and are using TS then you are properly where you want to be.

skybrian2• 2 years ago

I use branded types for database id’s to avoid mixing them up. It seems like better documentation and might catch some errors, but mixing up database id’s seems like an uncommon error, so hard to say.

shadowgovt3• 2 years ago

Probably not.

I could definitely see using something like this to force some constraints on my favorite bugbear for my problem domain: values that should have units. It matters a lot if "time" is nanoseconds, microseconds, or seconds, but most time-related functions just take in "number" like that's okay and won't cause thousand- or million-fold magnitude errors.

This is one way to provide some language safeguarding against treating 5 nanoseconds as the same as 5 microseconds.

chowells• 2 years ago

You've never had values that are only valid within a specific context and wanted to prevent using them incorrectly?

IshKebab• 2 years ago

Yeah structural typing assumes that all fields with the same name & type mean the same thing, but that clearly isn't always the case.

brigadier132• 2 years ago

You don't use them but your favorite libraries do.

maeil• 2 years ago

This is very accurate, in particular when the output type of something depends on the input type.

Data validation, typed database access, or functional programming libraries are good examples. Particularly the modern, leading libraries of such areas, if you look into their code you'll generally see very intricate typing. For FP libraries it's particularly tough. I like to use Remeda which emphasizes being very type-safe, but that means it's inherently more limited in what functions it can offer compare to other libraries which choose to compromise their type-safety. These kinds of techniques mean that libraries can offer greater functionality while remaining type-safe.

JJMalina2• 2 years ago

I think the example could be better in this article. Let's say you have a function that takes a database id, an email address, and a name. They're all strings. If you pass arguments to this function and you mess up the order for some reason then the compiler has no idea. Hopefully your unit tests catch this but it won't be as obvious. Branded types solve this problem because you can't pass a name string as an argument that is expected to be an email address.

If you argue that this is not a common problem in practice, then I tend to agree. I haven't seen code with mixed up arguments very much, but when it does happen it can have bad consequences. IMO there is not a big cost to pay to have this extra safety. In TypeScript it's ugly, but in other languages that natively support this typing like Scala, Rust, Swift and Haskell, it works nicely.

LadyCailin• 2 years ago

That’s just plain encapsulation, if I understand you correctly. Branding, on the other hand, prevents complex types from being confused.

contextnavidad• 2 years ago

because you can't pass a name string as an argument that is expected to be an email address

Unless you accidentally create the wrong branded type? Which is as likely as disordered arguments.

As you stated, tests should cover this case trivially, I don't see the value in added type complexity.

amatecha3• 2 years ago

Yeah no, IMO this seems totally extraneous and a layer of complexity not worth introducing to any project. I've never encountered a case where I care that I need to differentiate between two types of exactly the same structure, and my gut feeling (without actually prototyping out an example) is that if this actually makes a difference in your code, you should probably be making the differentiation further up in the flow of information...

eyelidlessness7• 2 years ago

Not necessarily wrong. You’re probably doing the same work at runtime. That might be either just as good (a subjective preference) or more correct (for certain kinds of dynamism) depending on context. In some cases, there are clear static invariants that could be guaranteed at compile time, and some folks will be more inclined to squeeze as much out of that as possible. In my experience, the benefits of that vary wildly from “total waste of time” to “solves a recurring and expensive problem for good”, with a lot in between.

CapsAdmin• 2 years ago

The need for tricks like this (and other complicated types) is simply not there.

It just depends on how constrained by types you want your code to be and how much time and effort you're willing to spend maintaining and writing code that fits within those constraints.

Sometimes complicated types are introduced because you want to maintain editor features such as find by reference and the ability to refactor later. When it works, removing or adding new features feels fast, easy and safe.

In the articles case you could differentiate between an email string type and a user id string type. Maybe sometime in the future you want to change the id to an integer instead, so now that it's already distinguished you could find all those places where that's applied.

That's at least a selling point, in practice I've used this a few times but it doesn't come up that often. Sometimes the blast radius of a type isn't big so it's not worth doing.

jonathanlydall• 2 years ago

I can see this being useful and it seems about as neat a solution as you can currently get in TypeScript as it stands today, but it’s still cumbersome.

My feeling is that while you can do this, you’re swimming upstream as the language is working against you. Reaching for such a solution should probably be avoided as much as possible.

shadowgovt3• 2 years ago

as the language is working against you

Right, but this is one of those situations where a reasonable person could conclude "The language is not working to help me solve the problem I'm trying to solve." Sometimes you don't want JavaScript sloppiness and you also don't want TypeScript structural-type "sloppiness," desiring instead nominal types.

This is a clever way to use the existing infrastructure to get nominal types with no additional runtime overhead.

kristiandupont4• 2 years ago

I don't see why. I greatly prefer typescript's structural typing for almost everything. But id's in data models are an exception, so I use branding for those. It works perfectly, the only overhead is in the write-once declaration and now I am protected from accidentally using an AccountId where a MemberId was expected, even though they are both just strings.

cush8• 2 years ago

Yes! I've wanted this in Typescript for ages! Is it possible to brand primitives though?

amatecha3• 2 years ago

How do ids of different types accidentally get into a place they shouldn't be? Is this simply a case where someone mistakenly passes along a property that happens to be called "id", not noticing it's an account id rather than a member id (as in, an implementation error)?

jrockway• 2 years ago

Rather, I think Typescript's philosophy of not having a runtime is simply wrong. Other statically typed languages retain type information at runtime. I don't understand why that was so important to explicitly exclude from Typescript.

nosefurhairdo• 2 years ago

If we needed a special Typescript runtime to use Typescript it would become nearly useless. The vast majority of Typescript becomes JavaScript running in Node or V8.

The web is stuck with JavaScript, and Typescript is a tool to help us write maintainable JavaScript.

recursive3• 2 years ago

Static typing information isn't retained at runtime. e.g.

    ListInterface list = new ConcreteList();
    let runtimeType = GetTypeOf(list); // will be `ConcreteList`, not `ListInterface`

This is an imaginary java-like language, but I'm not aware of a statically typed language that gives you the static type resolutions at run-time, outside of cases like implicit generic resolutions and things like that.

vundercind2• 2 years ago

So it’s Just JavaScript and the risk of adopting it is basically zero.

It’s the thing that made it an easy sell after everyone got turned off by the long-term experience of Coffeescript and such. It’s the reason various “better” typed languages that run on top of JS have flopped except with enthusiasts.

mason554• 2 years ago

The decision between structural and nominal typing has nothing to do with whether you retain type information at runtime.

TS could have just as easily chosen nominal typing + a simple way to do typedefs and had everything else work like it does now. But structural typing gives you a lot of other useful features.

klysm6• 2 years ago

I disagree. If we had a runtime we'd have to inject that all over the place and compatibility with javascript wouldn't be a given.

Quekid5• 2 years ago

Other statically typed languages retain type information at runtime.

Funnily enough, Haskell[0] doesn't... unless you ask it to by explicitly asking for it via Typable[1].

[0] ... which is renowned/infamous for its extremely static+strong typing discipline. It is nice that one can opt in via Typeable, but it's very rare to actually need it.

[1] https://hackage.haskell.org/package/base-4.19.1.0/docs/Data-...

hpeter• 2 years ago

Typescript is not a real standalone language. It's just javascript after all.

Try Dart, maybe you like it. It's like TS but with it's own runtime.

JJMalina2• 2 years ago

Zod has branded types: https://zod.dev/?id=brand it works really nicely with Zod schemas

spankalee8• 2 years ago

To me the real benefit of branded types is for branded primitives. That helps you prevent mixing up things that are represented by the same primitive type, like say relative and absolute paths, or different types of IDs.

You really don't need the symbol - you can use an obscure name for the branding field. I think it helps the type self-document in errors and hover-overs if you use a descriptive name.

I use branding enough that I have a little helper for it:

    /**
     * Brands a type by intersecting it with a type with a brand property based on
     * the provided brand string.
     */
    export type Brand<T, Brand extends string> = T & {
      readonly [B in Brand as `__${B}_brand`]: never;
    };

Use it like:

    type ObjectId = Brand<string, 'ObjectId'>;

And the hover-over type is:

    type ObjectId = string & {
      readonly __ObjectId_brand: never;
    }

cush8• 2 years ago

Sorry, how do you apply it to branding primitives? The basic

    const accountId: Brand<string, "Account"> = "123654"

Has the error

    Type 'string' is not assignable to type '{ readonly __Account_brand: never; }'

beeboobaa3• 2 years ago

This error is, in fact, the point. It keeps you from accidentally assigning a normal string to a branded string

You have to make a function to apply the brand via a cast, the article explains this as well.

    function makeObjectId(id: string): ObjectId {
        return id as ObjectId;
    }

amatecha3• 2 years ago

Yeah in TS' own playground example they don't create a Symbol, they just intersect it inline: https://www.typescriptlang.org/play#example/nominal-typing

spankalee8• 2 years ago

Nice.

I don't love that example though, because the brand field's value of a string literal will make it seem like the object actually has a property named `__brand` when it doesn't. `never` is the best brand field type as far as I can tell.

nsonha6• 2 years ago

do you need readonly with never?

samtheprogram2• 2 years ago

Yes, otherwise consumers could try reading the property (that doesn’t exist).

385• 2 years ago

Is all Typescript unreadable, or is that just your style?

highwaylights• 2 years ago

It’s very readable to me, and is much cleaner than the notation in the article.

Is your problem the line wraps in the parent’s comment?

spankalee8• 2 years ago

Are all of your comments devoid of content, or just this one?

leecommamichael• 2 years ago

The Odin language has a ‘distinct’ type-qualifier which accomplishes this tersely. It’s a big part of the type system, and C’s type-system for that matter.

techn00• 2 years ago

Very useful for DDD, like having an Email type, or String100 (string of 100 characters)

mason554• 2 years ago

Works very well too for any kind of validation or encoding. Anything that accepts input from the outside world can accept a string. And then everything else in the app can work with a "SafeString" and the only way to create a safe string is to send a string through a string escape function (or whatever makes sense for your app).

Works especially well if you're using any kind of hexagonal architecture, make your functional core only accept validated/escaped/parsed/whatever types, and then the imperative shell must send any incoming data through whatever transformation/validation/etc before it can interact with the core.

zbentley• 2 years ago

It's a clever trick, but the compiler errors leave a lot to be desired. If a TS library makes heavy use of nominal (branded/distinct) types in a domain where accidentally passing values of the wrong type is common, I can imagine a lot of library users being more confused, not less, by code that uses this approach.

The article reads more like an endorsement of languages that do structurally-aware nominal typing (that is, languages that are nominally typed but that have awareness of structural equivalence so that zero-cost conversions and intelligible compile-time errors for invalid conversions are first class) than a persuasive case for the symbol-smuggling trick described.

shadowgovt3• 2 years ago

This is one of those frustrations I encounter with C++.

C++'s templating lets express some very powerful type constraints... But good luck reading the compiler errors generated by someone else's very powerful type constraints that you haven't fully grokked to an implementation level.

eropple• 2 years ago

Generally speaking, I wouldn't use branded inputs for libraries. Branded types make a lot more sense to me when working in business-logic cases, to identify data at the edge of a bounded context and tracing through the system. A library is downstream of that and the code that requires the branded type should be controlling the inputs to the library.

eyelidlessness7• 2 years ago

I’ve found TypeScript errors can be made a lot easier to understand with some forethought about how invalid types are defined in the first place. For instance, a many-branched conditional type may be much easier to understand (both as a library user and as a reviewer/maintainer of the library code itself) if each `never` (or whatever actual failure case) is instead a string literal describing the nature of the failure. And better still if it can be templated with an aspect of the input type to highlight what aspect of it triggered the error.

jibbit• 2 years ago

or a tagged type if you're old enough to have ever been exposed to another language

mirekrusin10• 2 years ago

Flow is much better with opaque types.

Also nominal types for classes.

And correct variance.

And adhering to liskov substitution principles.

And exact object types.

And spread on types matching runtime behavior.

And proper no transpilation mode with full access to the language.

And has 10x less LoC than ts.

ps. before somebody says "flow is dead" have a look at flow contributions [0] vs typescript contributions [1]

[0] https://github.com/facebook/flow/graphs/contributors

[1] https://github.com/microsoft/TypeScript/graphs/contributors

eyelidlessness7• 2 years ago

FWIW, classes in TypeScript become nominal types when they have a non-public member. But I definitely do feel real FOMO over Flow’s opaque types.

mirekrusin10• 2 years ago

Yes, ts is full of this kind kind of adhoc-ifs-like glued together, also exactness check only when it's literal object etc.

Flow is more principled.

nsonha6• 2 years ago

adhering to liskov substitution principles

what does this even mean?

And has 10x less LoC than ts

Prolly b/c Flow isn't able to express the advanced types (albeit with 10x LoC) in the first place.

mirekrusin10• 2 years ago

You can google, gpt or look at wikipedia for "liskov substitution principles". It's related to object oriented programming, more specifically to inheritance and what is allowed as substitution as superclass vs subclass depending on which position it sits in argument vs return value. It's very interesting read if you don't know about it and you're using OOP.

What advanced types do you have in mind?

ps. the way you're using "albeit" sounds like you think flow has 10x larger codebase, it has 10x smaller codebase

recursive3• 2 years ago

Check out the react codebase, which is presumably the flagship use of flow. It has hundreds of FLOW FIXME annotations. It's easier have a lot of features and small code base if the you don't handle the difficult cases.

hu3• 2 years ago

Only hundreds? Not bad then.

I expected thousands.

mirekrusin10• 2 years ago

It's the other way around.

Handling difficult cases leads to more type errors.

If type system is lax, it won't flag them but they can fail at runtime.

React has very little of $FlowFixMe annotations for its codebase.

In typescript projects on the other hand it's normal to see unsafety as normal code (casting, non null assertions, implicit and explicit anys etc).

vundercind2• 2 years ago

Tried Flow first, back in the day. I was ready to give up the whole idea as not-at-all-worth-the-trouble if Typescript had been as mediocre an experience.

Fortunately it wasn’t and now I get to not-hate working in JavaScript.

mirekrusin10• 2 years ago

Yes there was a time when atom/vscode integration was shit.

They also fucked up typings in terms of community management.

Those two alone probably put them into downward spiral.

But the language is being developed with activity stronger than ever.

And it is well designed and pleasure to code in.

baw-bag• 2 years ago

flow is dead (for jobs). I'm gonna annihilate Dart (apart from jobs)

mirekrusin10• 2 years ago

java is great for jobs as well.

yen223• 2 years ago

Flow regularly crashed with bizarre segfaults errors, the last time I used it.

mirekrusin10• 2 years ago

Sounds like vscode integration few years ago, yes.

klysm6• 2 years ago

The downside of structural typing

dimitrisnl• 2 years ago

Selfish plug about the same topic https://dnlytras.com/blog/nominal-types

kevincox• 2 years ago

I also wrote something like this and came up with something similar to yours: https://kevincox.ca/2023/03/21/lying-to-typescript/#summary

However I just inlined the "tag". Also like yours but unlike OP there is no runtime tag. Which can be a pro (no extra code) or a con (can't do runtime checks).

dvt7• 2 years ago

Weird idea, as types in TS are structural by design. If this is something you need, it smells like "runtime checking" not amending the type system.

williamdclt3• 2 years ago

Design doesn’t cover all use cases. There’s nothing weird about wanting different types for “user id” and “organisation id” so that you don’t use the wrong argument by mistake

dvt7• 2 years ago

While you're right that branding makes passing arguments more ergonomic, I will still always be able to do `as OrgId` or `as UserId` so you need to do have some failure handling anyway, unless you're okay with blowing up in the user's face.

RHSeeger• 2 years ago

Right, but there are times when structural typing is not the right choice. And runtime checking is ... suboptimal. I mean, saying runtime checking is the right choice is like saying a type system isn't necessary, because you have automated tests. They're great, and they're a tool that provides value... but so too are types.

dbalatero2• 2 years ago

And runtime checking is ... suboptimal.

Especially on the frontend, where your `throw new Error("Bad input type")` might brick the entire app if uncaught. I'd much rather hear an earful from TypeScript before a bundle is ever produced.

tshaddox3• 2 years ago

If this is something you need, it smells like "runtime checking" not amending the type system.

This is both! The primary point of branded types is to allow you to use the type system to ensure that a particular runtime check has taken place.

dvt7• 2 years ago

The primary point of branded types is to allow you to use the type system to ensure that a particular runtime check has taken place.

I see. This is kind of cool, though the branding can still be broken via down-the-stream mutations. Would be nice to enforce re-branding every time a variable is changed, but that seems like a lot of overhead.

wwwigham• 2 years ago

TypeScript _itself_ has a branded primitive string type it uses internally.[1] Dedicated syntax for creating unique subsets of a type that denote a particular refinement is a longstanding ask[2] - and very useful, we've experimented with implementations.[3]

I don't think it has any relation to runtime type checking at all. It's refinement types, [4] or newtypes[5] depending on the details and how you shape it.

[1] https://github.com/microsoft/TypeScript/blob/main/src/compil... [2] https://github.com/microsoft/TypeScript/issues/4895 [3] https://github.com/microsoft/TypeScript/pull/33038 [4] https://en.wikipedia.org/wiki/Refinement_type [5] https://wiki.haskell.org/Newtype

erik_seaberg• 2 years ago

This works because casts are allowed to quietly create values whose types are wrong. It would have been better if the cast added a runtime check, or at least we distinguish sound (checked) and unsound casts the way C++ does.

I think Haskell avoid this by actually requiring you to write sound conversion functions between phantom types (it helps that phantom types don't involve any visible state at runtime).

diarrhea• 2 years ago

As a TypeScript beginner, I was bitten by this. Typing in TypeScript feels quite bad for some reason; a lot of effort for effects which are still potentially wrong at runtime. I didn’t struggle so much in Python, Rust or C#, for example. Python is surprisingly… sound? in comparison. It can do nominal as well as structural typing.

beders• 2 years ago

Ah, the magical disappearing type system - now being used for nominal typing.

I'm curious to see what the JS code looks like for casts and type checks in that case.

williamdclt3• 2 years ago

Nothing special about casts and type checks. It’s just a simpleish workaround for when nominal typing is more useful

klysm6• 2 years ago

Ah, the magical disappearing type system - now being used for nominal typing.

More like: magical disappearing type system is not nominal: hacky workarounds ensue.

Slix• 2 years ago

This is also useful for having a type that needs to be verified in some way before being used or trusted. UnverifiedLoginCookie vs. VerifiedLoginCookie

lang_agnostic• 2 years ago

Isn't this just phantom types in other programming languages?

valcron1000• 2 years ago

More like `newtype` with implicit `coerce`

thepaulmcbride4• 2 years ago

Anytime I’ve come across the need to do this, I’ve found a class is a better and less complicated solution.

I really like the pattern of value objects from Domain Driven Design. Create a class that stores the value, for example email address.

In the class constructor, take a string and validate it. Then anywhere that you need a valid email address, have it accept an instance of the Email class.

As far as I understand classes are the only real way to get nominal typing in TypeScript.

CharlieDigital• 2 years ago

Classes can also make use of the native `instanceof` JavaScript operator [0].

It is also possible to then infer a type from a class so you can use both the class where you want to discriminate types and the type where you really only care about the shape.

The absolutism towards OOP/FP -- instead of embracing the right use cases for each -- always ruffles me in the wrong way. C#, for example, does a great job of blending both OOP and FP (borrowing heavily from F# over the years). JS and by extension TS has the same flexibility to use the right paradigm for the right use cases, but it seems that everyone wants to be on one end of the spectrum or the other instead of accepting that JS is an amalgamation.

Evan You had a great quote on this where he correctly calls out much of the complexity and performance issues with React as being rooted in pushing against the language rather than embracing it.

[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

thepaulmcbride4• 2 years ago

Classes are very underutilised in TypeScript. I recently introduced them to our codebase at my day job and got a fair bit of pushback because it wasn’t “JavaScripty” enough.

eyelidlessness7• 2 years ago

The absolutism towards OOP/FP

… also doesn’t need to proscribe use or non-use of classes. People were doing OOP in JS long before classes were added to the language. I routinely use classes in a FP style because they’re excellent for modeling value types with a stable structure.

schwartzworld• 2 years ago

JS classes are a great fit for FP. They're just functions with closures and a little syntactic sugar.

spankalee8• 2 years ago

Yeah, classes are generally better than branded types for objects (unless you're just building discriminated unions).

What's particularly better these days is that you get nominal typing and brand checks with standard private fields:

    class Foo {
      #brand;

      static isFoo(o): o is Foo {
        return #brand in o;
      }
    }

superamadeus2• 2 years ago

This is really neat, thank you for sharing!

iainmerrick• 2 years ago

I don’t quite see why you’d need to brand simple objects at all! Just give them meaningful field names.

Branding primitives is useful because you don’t otherwise have a name that you can control (e.g. feet versus meters as was suggested elsewhere in this thread, both of which would have type “number”).

The article starts with the example of two different object types with field “x: number”. In that situation you should be branding the field, not the object! If the field has the same name and the same branded type, structural typing is correct for that object shape.

mbwgh• 2 years ago

Is this different/better than using `instanceof`?

tshaddox3• 2 years ago

As far as I understand classes are the only real way to get nominal typing in TypeScript.

Although classes and instances are ultimately structural, right?

    let foo = new Foo();
    assert(foo.constructor == Foo);

thepaulmcbride4• 2 years ago

Yep, you’re absolutely right

chrismorgan• 2 years ago

foo.constructor actually doesn’t matter; foo.__proto__ == Foo.prototype is the one that actually makes things chug, and you can change the class of a value by changing its __proto__.

theteapot• 2 years ago

Anytime I’ve come across the need to do this, I’ve found a class is a better and less complicated solution ... As far as I understand classes are the only real way to get nominal typing in TypeScript.

How are classes going to help? As far as I understand TS is structural period. Ex this is valid (!):

  class Email {
      constructor(public email: String) {}
  }
  let x: Email = new Email('foo@foo.com')
  let y = { email: '73'}
  x = y;

superamadeus2• 2 years ago

I had the same initial reaction, but it turns out that if you have at least one private member, even with the same signature, it works as the parent comment suggests.

For example, these two classes are distinct to TypeScript:

    class Name {
        constructor(private value: string) {}

        getValue() {
            return this.value;
        }
    }

    class Email {
        constructor(private value: string) {}

        getValue() {
            return this.value;
        }
    }

    const email: Email = new Name(“Tim”); // Error: (paraphrasing) conflicting private declaration of “value”.

DanielHB3• 2 years ago

I believe what the OP meant by "to get nominal typing in TypeScript" is that the type information is available at runtime through the use of the `instanceof` keyword.

I am surprised your code doesn't give an error, x and y are definitely not the same thing because `x instanceof Email` would be false at the end of that code. But like you said, to TS x and y are indeed the same type because they have the same structure. In practice both can be used interchangeably in the code (even if Email extended another class) with the sole exception of the `instanceof` keyword.

svieira2• 2 years ago

Given a Branded / Nominal interface, they look about the same usage wise but the branded type disappears at runtime (whether that is a benefit or a detriment depends on your use case):

    type Email = Branded<string, 'email'>

    function Email(maybeEmail: string): Email {
      assertIsEmail(maybeEmail);
      return maybeEmail;
    }

    function assertIsEmail(value: string): asserts value is Email {
      if(!isEmail(value)) throw TypeError("Not an email");
      return value;
    }

    function isEmail(value: string): value is Email {
      return value.contains("@");
    }

Versus:

    class Email {
      #email: string;
      public constructor(maybeEmail: string) {
        if(!isEmail(maybeEmail)) throw TypeError("Not an email");
        this.#email = maybeEmail;
      }
      valueOf() {
        return this.#email;
      }
    }

bazoom42• 2 years ago

I think Typescript need nominal type aliases for primitives.

satvikpendem• 2 years ago

Reminds me of another sort of type-driven development, making invalid states unrepresentable: https://geeklaunch.io/blog/make-invalid-states-unrepresentab...

herpdyderp• 2 years ago

The implementation for `RemoveBrand` is incorrect: it currently grabs all property types of `T`, it's not removing the property `[brand]` from `T`. It should be `Omit<T, typeof brand>`

munk-a2• 2 years ago

Isn't this just the classic issue of inferred typing coming back to bite us in the way everyone originally predicted? Go runs into the same issue where wildly different types may be considered the same based purely on coincidental naming and matching against interfaces the original authors had no intent to match against. At the end of the day I think the easier system to work with is one in which all type compatibility needs to be explicitly declared - if your array is iterable defining that it implements iterable lets your compiler shout at you if iterable suddenly gets another abstract method that you didn't implement - and it makes sure that if you add a method `current` to a class it doesn't suddenly means that it properly supports iterable-ity.

Determining types by what things appear to do instead of what they state they do seems like a generally unnecessary compromise in typing safety that isn't really worth the minuscule amount of effort it can save.

skybrian2• 2 years ago

I haven’t run into interfaces coincidentally matching in Go. Have you? It might happen more easily for primitive types, though, and Go does have a way to declare new types:

   type UserId string

klysm6• 2 years ago

Are these simple aliases or nominally distinct types?

Aeolun2• 2 years ago

I mean, they have to stay backwards compatible with Javascript. That kind of limits your options.

munk-a2• 2 years ago

Not particularly - they could use distinct tokens (i.e. these brandings) on all types implicitly.

cageface• 2 years ago

The other problem I've found with structural types in Typescript is that it can lead to some very complex type specifications. Instead of carefully thinking about and naming the entities in your system you can get some very hard to parse type spaghetti.

hankchinaski• 2 years ago

Maybe is me but this seems way overengineered

efilife• 2 years ago

Everytime I read anything about typescript I think of this

epolanski3• 2 years ago

An example of what you can implement on top of branded types that I want to share with fellow hackers:

- currencies

You may have some sort of integer representing the number of cents of some currency and you want to avoid doing operations between the wrong currencies (such as adding euros and pesos).

You can create branded types and functions that work on those Euro branded numbers and then decide how to do math on it. Or numbers representing metals and such.

It's useful in other scenarios such as a, idk, strings, you could theoretically brand strings as idk ASCII or UTF-8 or the content of an http body to avoid mixing those up when encoding but I want to emphasize that often many of those hacks are easier to be handled with stuff like dictionaries or tagged unions.

An example of what can be achieved with similar approaches (beware it's oriented for people that are at least amateur practitioners of functional programming) is Giulio Canti's (an Italian mathematician and previously author of t-comb, fp-ts, io-ts, optic-ts, and now effect and effect/schema), the money-ts library:

https://github.com/gcanti/money-ts

atonse• 2 years ago

Thanks, the currency stuff was a great real-world example that crystallized where this would be nice to have at a core level with typescript to severely reduce the odds of doing cross-currency math.

spankalee8• 2 years ago

As much as I love branding, I would be hesitant to use it for critical math and where you might want to inspect the type at runtime as with money.

Branding is easily circumvented, so it's best as a developer hint that helps document APIs and alerts us to common mistakes as an incremental improvement over primitives.

For money and similar I would use objects and a custom math library.

epolanski3• 2 years ago

You can parse before brand thus enhance and enforce runtime correctness.

vaylian• 2 years ago

Another example: inches versus meters. We have lost a mars probe due to a misinterpretation of the numbers: https://www.latimes.com/archives/la-xpm-1999-oct-01-mn-17288...

robocat• 2 years ago

I have seen plenty of currencies come and go in my life: weird to lock that into your codebase.

And I'm struggling to think of where in a codebase I might want to hardcode Pesos or Euros.

aleksiy123• 2 years ago

Anyone else sometimes get more sucked in to perfectly typing stuff instead of writing code.

I guess working in the pure logic and formalism of types is just addictive.

I love it.

farnsworth• 2 years ago

Yes, if you do a good job it removes a lot of mental overhead for building the feature or refactoring it later.

Although if you do a bad job it might add a lot...

rowanG077• 2 years ago

How do you ensure someone doesn't reuse a brand string? Seems pretty brittle to me.

black_puppydog• 2 years ago

Structural typing, and especially for primitives, with these work-arounds being so clunky and not built into the standard library, was the reason I started picking up Rust...

SergeAx• 2 years ago

Seems like patching earlier language architecture mistake. If you create custom types, you should not use duck typing on them. You should use typecasting, so the programmer would write something like `result = processEntityA(A(B))`

gmdrd2• 2 years ago

Is there something wrong with creating opaque types using this method?

  type ObjectId = string & { 
  readonly __tag: unique 
  symbol }

This way, we don't need to use `never`, but we still prevent the creation of a structurally equivalent type by mistake.

TypeScript: Branded Types

Related Stories