Comment by foooorsyth | Hacker News Reader

Comment by foooorsyth | Hacker News Reader

Parent Full thread

I read the article, thanks.

It makes the claims that (1) a string of a specific form (a hash) could be misused (eg. someone might call toUpper on it) or (2) passed in incorrect order to a function that takes multiple strings.

Named parameters / outward-facing labels (Swift) completely solves (2). For (1), the solution is just ugly. Just use the type system in a normal manner and make a safe class “Hash” that doesn’t allow misuse. And/or use namespacing. And/or use extensions on String. And/or add a compiler extension that looks like outward-facing labels but for return types. So many cleaner options than this nasty brand (yes, that’s the point of the article, but the solution is still hideous. Make it elegant).

Respectfully disagree on the elegance. This looks pretty neat to me:

    type Hash = Branded<string, "Hash">;

The point of branded types is, among other things, that you do not need to introduce a wrapper class which consumes additional memory.

Really? I'm surprised you mention memory is even a consideration, never even heard it raised as far as typing choices are concerned.

(More than) doubling the memory required for all of your integers would be silly. You could use `{userId: 12345}` everywhere, or you can use a branded type and it's just `12345` at runtime.

Are you worried about compiler memory consumption? Because it's not a class, it's a type, and it's erased at compile time.

Runtime. Not compiler.

None of this exists at runtime.

Well, they're talking about alternative solutions that do exist at runtime like wrappers.

Granted, it's hard to know exactly what solutions the person is pitching (the person they're responding to). This person presumably thinks renaming arguments like foo(string:) to foo(hash:) solves branded types. And then they vaguely gesture at other solutions like namespacing and 'safe classes'.

Reply on news.ycombinator.com