Hi, I own a library where I'd like to enforce usin...
# arrow-meta
p
Hi, I own a library where I'd like to enforce using named args in every API possible. I have a solution (sort of) how to achieve it for a single function (example), now I'd like to either have a reusable annotation that will leave the function signature intact, or have a way to emit such code for my whole Gradle module. I thought about a compiler plugin and arrow-meta as a tool that can make it easier. However, I don't really know where to start, if I need to publish something or it's fine to create something within my repo, and generally if it's a good path to solve my problem. Thoughts? :)
BTW, the docs seem broken - I see "Page Not Found" on a page that was linked somewhere: https://arrow-kt.io/docs/meta/apidocs/arrow-meta/arrow.meta/-meta/index.html
Also, is arrow-meta now called arrow-reflection? https://github.com/arrow-kt/arrow-reflection
Following the README, I should create a frontend tranformer right?
y
What I'd suggest is to have an annotation to mark those declarations with, and make those declarations internal, and then use KSP to generate public functions with the vararg trick that call the internal functions
p
ok, thanks! so arrow-meta/arrow-reflection is not a good fit for solving this problem? if so, why?
y
I think they can, but I'm not fully sure. Basically, the old frontend definitely would allow for this I think, but the new one (I'm pretty sure) doesn't allow you to change the signature of declarations. The new frontend is the default for Kotlin 2.0, which is coming out by the end of this year. Also, not sure if Arrow meta has support for new frontend yet, but with the new frontend you can declare custom checkers that can emit warnings, so actually what you can do is make a FIR plugin that declares a checker which reports an error if an annotated function is called without named arguments
p
ok, thanks! this certainly sheds some light on this problem. I'll try the KSP approach. I'm also wondering if not allowing to change the signatures of declarations is some kind of a limitation by design, it seems limiting. Limiting is sometimes good, but here altering the declaration would be a solution
y
Yes the FIR has a few of those "limitations by design" and for good reasons. The justification I heard is that they don't want people to create a whole new language that merely resembles Kotlin.
a
the documentation has been moved https://old.arrow-kt.io/docs/meta/ as part of the redesign of Arrow’s website