Just published my first technical blog post about solving the “method too large” error in Scala macros. If you’ve ever wondered how local methods are compiled or need to generate massive amounts of code at compile-time, this one’s for you!
I initially thought I’d stop after just one blog post, but what wouldn’t a person do to avoid studying for their thesis defence? Part two is now live.
The post showcases a Scala 3 macro that extracts default parameter values from methods and provides type-safe field access via Selectable and Computed Field Names.
Read the full post here: Type-Safe Access to Method Parameter Defaults in Scala - halotukozak
Scala Type Class Derivation with (almost) no macros
Just published a deep dive on how Scala 3’s native Mirror API and compile-time utilities eliminate the need for heavy reflection or macro-heavy libraries.
I’ve taken GenCodecs from the AVSystem’s scala-commons library and implemented them in Scala 3.
Full post in my blog. Feedback welcome!
me: I should get some sleep before my thesis defense
also me: writes 1,500 words about compile-time metaprogramming
Mapping over Scala 3 tuples usually ends in a mess of asInstanceOf because Tuple.map is just too generic.
I’ve been playing with clause interleaving and match types to fix this. The result is a mapAs[T] extension that proves a tuple is homogeneous at compile-time with zero runtime overhead.
No more unsafe casts, just type-level proofs that actually work.
I don’t know, it’s a bit hacky. Maybe it would be better to integrate homogenous tuples into the language itself. But I wouldn’t mind to see mapAs equivalent in the stdlib