```val myAnnotation = maybeAnnotatedClass.getAnnot...

# getting-started

[min]

val myAnnotation = maybeAnnotatedClass.getAnnotationByClassId(
    classId = ANNOTATION_CLASS,
    session = session,
)
    ?: return null
    .getKClassArgument(ANNOTATION_ARG)!!
    .classId!!

Is there a way to mark the end of the Elvis operand? The code above is rejected because the operator maximally munches the rest of the expression

[min]

val myAnnotation = maybeAnnotatedClass.getAnnotationByClassId(
    classId = ANNOTATION_CLASS,
    session = session,
)
    .let { nullable -> nullable ?: return null }
    .getKClassArgument(ANNOTATION_ARG)!!
    .classId!!

I constantly have to do this, which would have been fine if I could abstract out the .let { nullable -> nullable ?: return null } into its own extension function that I could reuse, but I cannot. I don’t want to wrap the whole function body in an Arrow nullable just so that I could call nullable.bind() either

val myAnnotation = maybeAnnotatedClass.getAnnotationByClassId(
    classId = ANNOTATION_CLASS,
    session = session,
)
    ?.getKClassArgument(ANNOTATION_ARG)
    ?.classId
    ?: return null

Also, please do not suggest alternatives such as this. I need to return early from the nullable (fallible) function if a given class is not annotated with the annotation class for my plugin (a failure mode). If it is annotated however but lacks a KClass argument, something inexplicable has gone profoundly wrong and there’s no recovery path for it which merits the use of !!

[phldavies]

Either .let { it ?: return null} or (expr ?: return null).restOfChain()

[Marat Akhin]

To my mind, considering different failure / recover modes for this chain call, I'd very much prefer to see two separate expressions in two separate variables here.

[min]

@Marat Akhin What do you mean?

[Marat Akhin]

val classAnno = maybeAnnotatedClass.getAnnotationByClassId(
    classId = ANNOTATION_CLASS,
    session = session,
) ?: return null
    
val classAnnoArgument = classAnno
    .getKClassArgument(ANNOTATION_ARG)!!
    .classId!!

[min]

The only thing that that separation achieves is overcoming the syntactic limit imposed by the maximal Elvis operator. classAnno is private to the call chain in the sense that it’s only the business of the chain and of nothing else. Why should it even be visible to the entire rest of the function? That’s one more binding for the reader of the function to keep track of in their head.

[phldavies]

You could also argue having a return hidden deep in the middle of a long chain of operations is just as harmful for the reader. Separation clarifies the stages and highlights the return. If you're worried about the scope of the function, extract a helper.

[Marat Akhin]

When you "hide" the implicit contract of

I need to return early from the nullable (fallible) function if a given class is not annotated with the annotation class for my plugin (a failure mode). If it is annotated however but lacks a KClass argument, something inexplicable has gone profoundly wrong and there’s no recovery path for it which merits the use of !! .

inside a call chain, to my mind, that's one more thing the reader needs to (now) carefully read and still track. I'd trade that for one more variable.

[min]

People can have opinions about this particular example, and that is their right. But the more important thing is that this friction point keeps coming up in call chains. Is there a way to mark the end of an Elvis operand?

[Marat Akhin]

I believe the most accurate description of the friction between you and Kotlin is: your code style is not exactly the code style Kotlin wants to encourage its users to write.

[phldavies]

Yes. By encapsulating the entire elvis expression in parentheses.

[min]

inline fun <T: Any> T?.elvis(f: () -> T): T {
    return this ?: f()
}

I think I could also declare an extension like this

[phldavies]

If it eases your style, you could introduce an inline fun <T: Any> T?.ifNull(f: () -> T): T helper so you can .ifNull { return null }

[min]

val myAnnotation = maybeAnnotatedClass.getAnnotationByClassId(
    classId = ANNOTATION_CLASS,
    session = session,
)
    .elvis { return null }
    .getKClassArgument(ANNOTATION_ARG)!!
    .classId!!

@phldavies I could live with this, thank you!

[phldavies]

I'd keep to standard stdlib naming style for it though (ifNull) although personally I'd keep to .let { it ?: return null }

[min]

.let { it ?: return null } is way too verbose given its frequency. But you make a good point about ifNull, thank you for your advice