A modern programming language that makes developers happier.

kotlinlang

```maybeAnnotatedClass
    .getAnnotationByClassId(
        classId = ANNOTATION_CLASS,
        session = session,
    )
    .coalesce { return Either.Bar(FactoryError.ClassNotAnnotated) }
    .getKClassArgument(ANNOTATION_ARG)
    .coalesce { return Either.Bar(FactoryError.ArgumentMissing) }
    .classId
    .coalesce { return Either.Bar(FactoryError.ArgumentInvalid) }```
Is it ever possible for `classId` to be `null` when the call to `getKClassArgument` has succeeded?

```public annotation class MyAnnotation(val kClass: KClass&lt;*&gt;)```
This is the annotation type definition the plugin tries to read.
```inline fun &lt;T: Any&gt; T?.coalesce(fallback: () -&gt; T): T {
    return this ?: fallback()
}```
Also, this is the definition of the `coalesce` utility in use.

It could be null in the red code, e.g. if the user will try to use definitely not-null type in LHS:
```fun &lt;T&gt; foo(@Ann((T &amp; Any)::class) x: Int) {}```

```(T &amp; Any)::class```
What am I looking at here? `&amp;` isn’t listed on <https://kotlinlang.org/docs/keyword-reference.html#operators-and-special-symbols|kotlinlang.org/docs/keyword-reference.html#…>

This is called "definitely non-nullable types" or DNN in short.
<https://kotlinlang.org/docs/whatsnew17.html#stable-definitely-non-nullable-types>

Even simpler example of get class call without classId (also in red code):
```fun &lt;T&gt; foo(@Anno(T::class) x: Int) {}```

I made my reproducible example too minimal. My `annotation class` is actually `@Target(AnnotationTarget.CLASS)`.
```@Target(AnnotationTarget.CLASS)
public annotation class MyAnnotation(val kClass: KClass<*>)```
Can `classId` still be `null` after a successful call to `getKClassArgument`?
```maybeAnnotatedClass
    .getAnnotationByClassId(
        classId = ANNOTATION_CLASS,
        session = session,
    )
    .coalesce { return Either.Bar(FactoryError.ClassNotAnnotated) }
    .getKClassArgument(ANNOTATION_ARG)
    .coalesce { return Either.Bar(FactoryError.ArgumentMissing) }
    .classId
    .coalesce { return Either.Bar(FactoryError.ArgumentInvalid) }```

Still could happen.
```class Outer&lt;T&gt; {
    @Ann(T::class)
    inner class Inner
}```
Also note, that annotation target doesn't prevent user to write the annotation anywhere. It prevents this code to be compiled (passed to backend). The frontend would still resolve it.