5 ms·

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.

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 2y ago
That’s just plain encapsulation, if I understand you correctly. Branding, on the other hand, prevents complex types from being confused.
- ebolyen 2y ago
  Branding works on primitive types as well, which is I think the most interesting use case. I would also agree that it's harder to confuse complex types as any single instance of a type is unlikely to overlap once you have a few fields.
- mason55 2y ago
  Not really, not for TS at least. If you just want to take a string and call it an email address and have your function only accept email addresses (the simplest use case) then you need to use branding. That's not encapsulation.
  - antifa 2y ago
    Or double your GC burden by using a wrapper class.
contextnavidad 2y 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.

LadyCailin 2y ago

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

ebolyen 2y ago
Branding works on primitive types as well, which is I think the most interesting use case. I would also agree that it's harder to confuse complex types as any single instance of a type is unlikely to overlap once you have a few fields.
mason55 2y ago
Not really, not for TS at least. If you just want to take a string and call it an email address and have your function only accept email addresses (the simplest use case) then you need to use branding. That's not encapsulation.
- antifa 2y ago
  Or double your GC burden by using a wrapper class.

contextnavidad 2y 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.