from Hacker News

Type-Safe Printf() in TypeScript

by wazbug on 3/24/24, 3:02 PM with 78 comments

• by jitl on 3/24/24, 5:59 PM

  Word of warning: the typescript compiler is not a particularly fast evaluator of recursive list manipulation programs, which is what these kinds of types are.

  They’re great in small doses where you really need them, but overuse or widespread use of complex types will make your build slower. It’s much better to avoid generics or mapped types if you can. The typings for a tagged template literal (without digit format specifiers like %d4) don’t require any generics.

  I love to write code like this, but I’m guilty of over using fancy types and I flinch when I see a typescript build profile showing 45s+ spent on generic types I wrote without realizing the cost.

• by eyelidlessness on 3/24/24, 5:50 PM

  Minor nit: I’ve found types like these—that is, iterative recursive types—benefit from using terminology common to map/reduce. And by “benefit from”, I mean become more understandable by a wider audience—not necessarily the HN audience per se, but quite likely teammates and future selves.

  Which is to say, these names almost always make types like this more clear:

  - Head: the first item in the input type you’re iterating through

  - Tail: the remaining items or unprocessed structure you’ll likely recurse on next

  - Acc (or pick your favorite “reduced” idiom): a named type for the intermediate product which will become the final type when you finish iterating. This can be provided as an optional parameter with an empty tuple as its default, largely modeling a typical reduce (apart from inverting the common parameter order).

  It also helps, IME, to put a “base case” first in the type’s conditions.

  When all of these names and patterns are utilized, the resulting type tends to look quite a lot like an equivalent runtime function you could encounter for producing the value equivalent to its type. This is great because you can even write the runtime function to match the type’s logic. This demonstrates both what the type is doing for people who find these “complex types” intimidating, and that the type accurately describes the value it’s associated with.

• by IceDane on 3/24/24, 3:56 PM

  Cool.

  There is a way to make this easier to extend, though: https://tsplay.dev/WGbEXm

  Can't tell off the top of my head if there are any disadvantages to this approach though.

• by crgwbr on 3/24/24, 9:28 PM

  Neat, but this is basically a ripoff of this post from a few years ago (even to the point of not including the runtime implementation):

  https://www.hacklewayne.com/a-truly-strongly-typed-printf-in...

• by pkkm on 3/24/24, 4:35 PM

  Reminds me of Idris: https://gist.github.com/chrisdone/672efcd784528b7d0b7e17ad9c...

  Recently though, I've been wondering whether advanced type system stuff is the right approach. It usually becomes pretty complicated, like another language on top of the regular language. Maybe it would be easier to have some kind of framework for compiler plugins that do extra checks. Something that would make it easy to check format strings or enforce rules on custom attributes, like Linux's sparse does, using plain imperative code that's readable to the average dev. Large projects would have an extra directory for compile time checks in addition to the tests directory they have now.

  But I haven't seen any language community do something like that. What am I missing?

• by yen223 on 3/25/24, 3:49 AM

  The interesting thing here is that the typesafe printf has its function arguments inferred from a string literal, at compile time. You can change the 9 to a "9" and see the type error even before running the code.

  This is something that most mainstream language's type system cannot do.

  (This may be obvious, but a lot of commenters here might have missed that.)

• by ruined on 3/24/24, 4:40 PM

  not sure i understand the utility of this when format strings and string template types already exist.

  you can also use typescript-eslint/restrict-template-expressions if you find yourself running into problems with that

  https://typescript-eslint.io/rules/restrict-template-express...

• by taeric on 3/24/24, 5:40 PM

  I've been kind of curious why tricks like this aren't used more to make sql and such. Heck, you could do similar tricks for shell execution. Or any general "string that is parseable." Seems we always take the route of not parsing the string as much as we can?

• by akira2501 on 3/24/24, 6:41 PM

  Am I missing something? This is just a toy implementation of a function prototype, that only includes integers and strings?

• by k__ on 3/24/24, 5:11 PM

  Nice!

  Now do ReScript. :D

• by beders on 3/24/24, 8:08 PM

  Honestly, if you spend that much code on a single `printf`, I will reject your PR and we will have a conversation about code maintenance and cost.

  Please don't adopt this.

• by Touche on 3/24/24, 4:03 PM

  Except missing the pesky runtime implementation. We don't need though, right? As long as the types say it's right.