In fact, a common pattern is to pass fully-qualified objects, e.g. `dimensions = {width: number, height: number}`, which makes mixing up variables even less likely since you have to explicitly specify them.
I literally just showed you how they don't. And you even go on to describe a pattern that makes the problem "even less likely" in the next sentence..
>Branding seems like a solution looking for a problem.
You do you.
I would rather put that information in the type system than in the variable name.
It prevents passing the wrong variable, is that not useful?
> Exactly.
I don't see how what I said agrees with what you said. Making it not an OrgId prevents the weird blowups.
A compilation error because you used the wrong type is not a blowup, it's preventing random blowups.
And you shouldn't be shuffling digits using string code, that's the point. If you have a way to transmute OrgIds, it should be a function that returns an OrgId.
I'd question whether people even need to know OrgId is a string.
I mean, with numbers it's even more confusing (this might be a TS bug?):
type SpecialNumber = number & { __brand: "SpecialNumber" };
let n: SpecialNumber = 42 as SpecialNumber;
n++; // works (but should break)
n+=1; // breaks
n = n + 1; // breaks
e.g. If I am parsing a string to a number via Number.parseInt, I don’t need a “: number” annotation because I can just call the variable “myNumber” and use that.
Branding a string is in many ways an extension on the idea of “branding” my “myNumber” variable as “: number” rather than leaving it as “: any”. Even if the TS type system is easy to bail out of, I still want the type annotations in the first place because they are useful regardless. I like reducing the number of things I need to think about and shoving responsibility off to my tools.
Right, and once I have a verified OrgId, I'll just keep using the `myOrgId` variable throughout my code, and I don't really need branding. Maybe I can do type aliasing to make the code easier to read (type OrgId = string), but hardline type verification via branding seems moot unless you can make strong runtime guarantees. I mean, don't get me wrong, I think it's a cute novelty, but it doesn't really do anything.
> But a new string will have a type like `string`, not `OrgId`, and then using it as an OrgId won't compile.
Exactly. Maybe I'm wrong, but in a real codebase, I bet branding would probably just confuse people. "Why can't I change the last number of an OrgId?"—well, you see, once you do that, you lose the brand so now you need to manually do `as OrgId`.