https://kotlinlang.org logo
Join Slack
Powered by
more releases this week: Arrow plug-in for Intelli...
# arrow
a
more releases this week: Arrow plug-in for IntelliJ now features gutter icons for 
Raise
https://arrow-kt.io/community/blog/2025/04/22/arrow-intellij-0-3/
K 11
arrow intensifies 6
🤩 4
amaze 1
e
Did the 
bind()
inspections in the plugin break? (Using IJ 2025.1 with K2 mode, plugin 0.3) I would've expected it to highlight that 
foo()
is missing a bind here?
a
that code is correct, 
x
is of type 
Either
and you can just print that
e
Ah okay. I thought it would highlight at least one of the `Either`s as being unused (similar to the detekt rule). Is there any example where it would highlight wrong/missing usage of 
bind()
?
a
I think in most cases this problem will be caught by the way you use 
x
afterwards. This particular example is not very representative, because string interpolation is one of those operations that "swallow" every type, regardless of the form. If you instead had tried to use 
x
"as an `Int`"
Copy code
val x = 1 + foo()
then you'd gotten an error because you're trying to use 
foo()
not as 
Either
, and the inspection would trigger
btw, not using a value will be handled in general by the new "unused value checker" https://github.com/Kotlin/KEEP/issues/412
amaze 1
l
> I think in most cases this problem will be caught by the way you use 
x
afterwards. I've thought about this a lot actually since adopting raise in a few codebases. In general that's correct, but in particular when type A is Unit and you're not going to do anything with the result, it's so easy to forget to add bind. I've often wondered if some kind of IDE feedback could catch this as a likely mistake. Maybe just in the case where the return value is an Either, invoked within a raise, and you ignore it?
But the updated Arrow plugin is great! Thank you for updating it for 2025.1 and I'm loving the gutter icons so far.
🥰 1
a
@leonhardt may you help me writing down what do you think should count as "forgetting to bind"?
l
The least complicated definition I can think of is "when a function that returns an Either is called within a Raise context and its return value is ignored." And I suppose "bind" might be overly specific as it could be otherwise handled with a 
getOr*
function, fold, etc.
a
the problem here is how to define "ignored". Because if you do 
val x = thingThatReturnsEither()
you're somehow "consuming" it
l
True! However in practice (at least in my case) the times I've gotten myself into trouble was only when I didn't assign it to anything and didn't call anything on the result (like in the invocation of doMagic in the screenshot above). If it's assigned to a variable, other helpful factors come in to play like the "unused variable" inspection and just having the value visible in the code. Perhaps either chaining something on the result or storing it on a variable could be enough to consider it handled, and be helpful enough for the purposes of an inspection?
a
those are actually the rules for the new "unused value checker" in 2.2 😄 but maybe I can implement something specific for 
Raise
, because we have some specific knowledge (for example, the types that you can call 
bind
on)
🎉 1
l
Ah, sounds like I should be looking forward to 2.2! I've been wondering if I should look to a linter for this type of concern. But if you do end up exploring the idea of something specific for Raise, one more thing I thought would be valuable is that functions like bind, fold, getOrElse could all satisfy/terminate the rule, but others that also return an Either like mapLeft would also trigger the rule.
Open in Slack
PreviousNext
Powered by