Hacker News Reader

Comment by bradrn | Hacker News Reader

In most languages, doing what this article describes is quite straightforward: you would just define a new type (/ struct / class) called ‘Hash’, which functions can take or return. The language automatically treats this as a completely new type. This is called ‘nominal typing’: type equality is based on the name of the type.

The complication with TypeScript is that it doesn’t have nominal typing. Instead, it has ‘structural typing’: type equality is based on what the type contains. So you could define a new type ‘Hash’ as a string, but ‘Hash’ would just be a synonym — it’s still considered interchangeable with strings. This technique of ‘branded types’ is simply a way to simulate nominal typing in a structural context.

View on HN

> In most languages, doing what this article describes is quite straightforward

Well, no. In most languages you wind up making a typed wrapper object/class that holds the primitive. This works fine, you can just do that in TypeScript too.

The point of branded types is that you're not introducing a wrapper class and there is no trace of this brand at runtime.

There's never any trace of typescript types at runtime.

If you wrapped the value to give it a “brand”, the wrapper would still exist at runtime. The technique in the article avoids that.

By “trace” I think GP meant that the required wrapper is still there at runtime but was only in service of the type system.

I think what they meant is that at runtime, you don't end up with objects that look something like:

  {
    "brand": "Hash",
    "value": "..."
  }

which would be the case if you used the more obvious wrapper route. Using this branding approach, the branded values are exactly the same at runtime as they would be if they weren't branded.

Well, enums.

I see where you are coming from but you are not quite understanding what the OP was saying

  class A {
    public value: number
  }
  class B {
    public value: number
  }
  const x: A = new B() // no error

This is structural typing (shape defines type), if typescript had nominal typing (name defines type) this would give an error. You could brand these classes to forcefully cause this to error.

Branding makes structural typing work like nominal typing for the branded type only.

It is more like "doing what this article describes" is the default behaviour of most languages (most languages use nominal typing).

Indeed, this is what I was trying to say!

yeah this is such a common misconception, but give the class example I showed and people just get it.

"structural typing" and "nominal typing" are still quite new terms for most devs

The article describes making "number" a different type, not A and B. It's true that making A and B different is a unique problem of TypeScript, but making number a different type is a common issue in many languages.

number is a primitive, branding a primitive can be done like in the example. To brand a class you could also add a private field.

Some languages all values are objects and in those languages then the branding argument applies the same way. For languages with nominal typing and primitives you need to box the type yes. Regardless the core of the issue is understanding how structural typing works vs nominal typing

> For languages with nominal typing and primitives you need to box the type yes.

But the compiler can elide the box for you. Haskell and Idris do this.

Haskell's newtype gives a nominal wrapper around a type without (further) boxing at at runtime. It is erased at compile time. Haskell does box their primitives, but via optimization they are used unboxed in some cases (like inside the body of a function). This technique could be applied to a language that doesn't box its primitives.

Idris also does this for any type that is shaped like a newtype (one data constructor, one argument). In that case, both on the scheme and javascript backend, a newtyped Int are represented as "bare" numbers. E.g. with:

    type Foo = MkFoo Int

a `MkFoo 5` value is just `5` in the generated javascript or scheme code.

You can fix that fairly easily using private variables:

  class A {
    private value: number
  }
  class B {
    private value: number
  }
  const x: A = new B() // error

You can also use the new Javascript private syntax (`#value`). And you can still have public values that are the same, so if you want to force a particular class to have nominal typing, you can add an unused private variable to the class, something like `private __force_nominal!: void`.

There is nothing to fix in my example, I was just highlighting the difference between nominal and structural typing. Adding a private field to the class is a form of branding (just like adding a Symbol key to a primitive).

The point is that Typescript does have nominal typing. It's used if a class is declared with any kind of private member, and for `unique symbol`s. So both in the case I showed, and the case shown in the article, we are using true nominal types.

In fairness, we're also using branded types, which I think is confusing the matter here*. But they are specifically branded nominal types. We can also create structurally-typed brands (before the `unique symbol` technique, that was the only possible option). I think that's what the previous poster was referring to by "simulated nominal typing" — this is distinct from using `unique type` and private members, which are true nominal typing.

* Note: Branded types aren't necessarily a well-defined thing, but for the sake of the discussion let's define them so: a branded type is a type created by adding attributes to a type that exist at compile time but not at runtime.

> which are true nominal typing.

One part that was not clear to me without testing, and since I do not use typescript regularly, was that you only get nominal typing between the classes that share the private member and if you start going out side that set you lose nominal typing. So you do not get a nominal type, but you can get a subset of types that when interacting with each other act as if they were nominal types.

So class Cat that uses `private __force_nominal!: void` can still be used as class Dog if Dog does not have `private __force_nominal!: void`.

Example[1]:

    class Dog {
        breed: string
        constructor(breed: string) {
            this.breed = breed
        }
    }

    function printDog(dog: Dog) {
        console.log("Dog: " + dog.breed)
    }

    class Cat {
        private __force_nominal!: string
        breed: string
        constructor(breed: string) {
            this.breed = breed
        }
    }

    const shasta = new Cat("Maine Coon")
    printDog(shasta)

edit - the above type checks in typescript 5.4.5

[1] modified example from https://asana.com/inside-asana/typescript-quirks

Without your example, I would've bet that TS uses structural typing for interfaces and nominal typing for classes.

I thought so too originally, was very surprised.

This is pretty much to flowjs does

flowtype documentaiton: https://flow.org/en/docs/lang/nominal-structural/#toc-object...

Example: https://flow.org/try/#1N4Igxg9gdgZglgcxALlAIwIZoKYBsD6uEEAzt...

> Branding makes structural typing work like nominal typing for the branded type only.

That's not quite true. Branding doesn't exist at run time, where as nominal typing usually does at some level. Classes exist at runtime, but most typescript types don't, so unless there's something specific about the shape of the data that you can check with a type guard, it's impossible to narrow the type.

> Classes exist at runtime

Not necessarily, depending on the language. Functional languages and system languages such as OCaml, Haskell, Rust, but also C (painfully) and C++ can represent wrapper types within a nominal type system at no runtime cost.

Haskell implements type classes via dictionary passing that don’t always get optimized away by the compiler so it does have a slight runtime cost:

https://okmij.org/ftp/Computation/typeclass.html#dict

In Rust, using trait objects also generates a vtable for dynamic dispatch so in that case traits are not fully erased:

https://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/sh...

My quotation was not good - I intended to reply to the argument that "nominal type do [exist at runtime] to some level". The newtype pattern in either Haskell or Rust is fully transparent at runtime.

As others have said, types don't necessarily exist at runtime. Types allow reasoning about the program source without executing it. Java is more the exception than the rule here; conventionally compiled languages such as C don't usually have types at runtime.

Good article on using branded classes with Typescript to avoid structural typing:

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

discussion: https://news.ycombinator.com/item?id=40146751

Depends what you mean by "most languages." I think it's clearer to say which languages have zero-overhead custom types.

Go has it. Java didn't used to have it so you would use wrapper classes, but I haven't kept up with Java language updates.

Java does not have it yet. Project Valhalla might bring it with Value types.

What you say is true, but after years of working with TypeScript (and about 15 years of Java before that) I'd say that from a purely practical perspective the structural typing approach is much more productive.

I still have PTSD from the number of times I had to do big, painful refactorings in Java simply because of the way strong typing with nominal types works. I still shudder to think of Jersey 1.x to 2.x migrations from many years ago (and that was a PITA for many reasons beyond just nominal typing, but it could have been a lot easier with structural types).

I love branded types (and what I think of their close cousin of string template literal types in TS) because they make code safer and much more self-documenting with minimal effort and 0 runtime overhead.

I think proper type inference along with some sort of struct literal syntax could make a lot of these problems go away without the need for structural typing. If you can create structs without explicitly mentioning the type (as long as it can be inferred), then you can use the same syntax for different types as long as their signatures are the same. Structural typing makes it too easy to accidentally pass something that looks like a duck but is actually a goose.

As an example, this syntax should be possible without structural typing or explicitly specifying the type of the value:

    // assuming a type signature of moveToPoint(Point)
    moveToPoint({x: 5, y: 10}) // the struct literal is inferred to be a Point

I believe F# has syntax like this, but it's been a while since I've used it so I don't remember the details.

> Structural typing makes it too easy to accidentally pass something that looks like a duck but is actually a goose.

This may be true, but in reality after 7 years of using TypeScript I don't think I've ever encountered this as a bug for an object (Record) type.

Even for branded types I find the value much more in self-documenting code than actual type safety, and I only have used branded types for primitives.

All valid javascript programs are valid typescript programs, so typescript necessarily must have structural type, it cannot have nominal type without breaking compatibility with javascript, which is a hard requirement.

Correct. My comment was about programming languages in general and not specific to TypeScript. :)

Overall I do like working with Typescript and structural typing does have some real advantages but, like just about everything in engineering, there are also tradeoffs.

Without some discipline you can create some very messy type spaghetti with TS. Nominal typing is more rigid but it can also force you to think more clearly about and carefully define the different entities in your system.

Typescript has good reasons to default to Structural Typing as untagged union type are one of the most used types in typing js code and Nominal Typing does not really have a good equivalent for them.

Nominal typing with correct variance describes OO (classes, inheritance and rules governing it <<liskov substitution principles, L from SOLID>>). Structural typing is used for everything else in js.

Flow does it correctly. Typescript treats everything as structurally typed.

As a side note flow also has first class support for opaque types so no need to resort to branding hacks.

You can do classes, inheritance, and LSP with structural typing just fine; look at OCaml.

You can still do this with classes in typescript:

class Hash extends String {}

https://www.typescriptlang.org/play/?#code/MYGwhgzhAEASkAtoF...

That's distinguishing the String class from primitive string. I don't think that would still work with another `extends String` the same shape as Hash.

For example: https://www.typescriptlang.org/play/?#code/GYVwdgxgLglg9mABO...

  class Animal {
    isJaguar: boolean = false;
  }

  class Automobile {
    isJaguar: boolean = false;
  }

  function engineSound(car: Automobile) {
    return car.isJaguar ? "vroom" : "put put";
  }

  console.log(engineSound(42)); // TypeScript complains
  console.log(engineSound(new Animal())); // TypeScript does not complain

Or, a version that's more inline with the post you're replying to.

Just add an Email class that also extends String and you can see that you can pass an Email to the compareHash function without it complaining.

  class Hash extends String {}
  class Email extends String {}

  // Ideally, we only want to pass hashes to this function
  const compareHash = (hash: Hash, input: string): boolean => {
    return true;
  };
  
  const generateEmail = (input: string): Email => {
    return new Email(input);
  }
  
  // Example usage
  const userInput = "secretData";
  const email = generateEmail(userInput);
  
  // Whoops, we passed an email as a hash and TS doesn't complain
  const matches = compareHash(email, userInput);

https://www.typescriptlang.org/play/?#code/MYGwhgzhAEASkAtoF...

Oops you’re right!

Great example of something that does not work. Javascript classes are structural by default, Typescript does nothing there.

https://www.typescriptlang.org/play/?#code/MYGwhgzhAEASkAtoF...

and works correctly in flow [0]

[0] https://flow.org/try/#1N4Igxg9gdgZglgcxALlAIwIZoKYBsD6uEEAzt...

Btw, there are quite a few language that have nominal typing, but use the equivalent of structural typing in their unions.

Eg in Rust or Haskell you can distinguish `Option<Option<bool>>`, but not in these languages. I guess Python and Typescript are examples of these?

Reply on news.ycombinator.com