6 ms·
> In this case where the wrong order of parameters was the issue, you can solve it with Template Literal Types You can solve the issue in this particular examp
by mattstir 2y ago
> In this case where the wrong order of parameters was the issue, you can solve it with Template Literal Types
You can solve the issue in this particular example because the "hashing" function happens to just append a prefix to the input. There is a lot of data that isn't shaped in that manner but would be useful to differentiate nonetheless.
> And for `hash.toUpperCase()`, it's a valid program.
It's odd to try and argue that doing uppercasing a hash is okay because the hash happens to be represented as a string internally, and strings happen to have such methods on them. Yes, it's technically a valid program, but it's absolutely not correct to manipulate hashes like that. It's even just odd to point out that Typescript includes string manipulation methods on strings. The whole point of branding like this is to treat the branded type as distinct from the primitive type, exactly to avoid this correctness issue.
- treflop 2y agoThe real problem is that hashes as strings is wrong. Hashes are typically numbers. Do you store people's ages as hex strings?
- mattstir 2y ago> Hashes are typically numbers If we want to get really pedantic, hashes are typically sequences of bytes, not a single number, so really `UInt8Array` is obviously the best choice here. It wouldn't fix the whole "getting arguments with the same types swapped around" issue though. Without named parameters, you have to pull out some hacks involving destructuring objects or branded types like these.