Photo by Ben Stern on Unsplash

At the time of writing this article, Kotlin compatibility for IR backend is in Alpha status and the compiler plugin API is Experimental. As such, information contained in this article about IR and compiler plugins could be out-of-date or incorrect. If official documentation exists, please refer to it first.

I’ve been wanting to write this series of blog posts for a while. Inspired By Kevin Most’s 2018 KotlinConf talk — Writing Your First Kotlin Compiler Plugin — I wanted to show how we could write our second compiler plugin, something IR based that works on all Kotlin targets.

In this…

The kotlin-power-assert Kotlin compiler plugin is great (I may be biased as its author) as it enables diagramming of assert function calls. As the plugin grows and matures I’m discovering new use cases. One I wanted to try is the idea of soft assertions which many assertion libraries support. Let’s take a look quickly at an example of verifyAll from the Spock Framework.

def "offered PC matches preferred configuration"() {
def pc = shop.buyPc()

verifyAll(pc) {
vendor == "Sunny"
clockRate >= 2333
ram >= 406
os == "Linux"

The example above is straight from the documentation…

I’ve been playing with Kotlin/JS and React lately. I’ve been wanting to learn more about frontend development, and since I’m very familiar with Kotlin, thought Kotlin/JS and React would be a good entry point.


I’m not even going to pretend to be able to explain React. You should go read the official documentation if you want to learn more. A quick primer: React enables the creation of Components which are reuseable and composable and built from other components and standard HTML tags using a XML-like syntax called JSX. Components can be stateful and take properties as inputs. …

I like to follow the kotlinx.coroutines library closely on GitHub. Not really because I have anything to contribute, but because there is so much to learn!

Take it’s use of the RequiresOptIn annotation (previously Experimental in Kotlin pre-1.3.70). There are some really nice ways this annotation is used, especially when introducing new library features like Flow and letting you know that parts of it are still experimental with the FlowPreview annotation.

However, the one that sticks out to me is the InternalCoroutinesApi annotation. This annotation marks APIs that have to be public but should not be used outside the library…

At the time of writing this article, Kotlin IR is experimental. As such, information contained in this article about IR could be out-of-date or incorrect. If official documentation for Kotlin IR exists, please refer to it first.

Ever since learning about them, I’ve been very interested in Kotlin compiler plugins. Even the limited list of official supported plugins hint at the potential available. A plugin like kotlin-serialization shows how it is possible to generate code for marshalling a Kotlin class. A plugin like allopen shows it’s possible to transform classes to be non-final at runtime. …

Kotlin introduced inline classes in 1.3 as an experimental feature. They allow wrapping of a single value which is inlined at compile time. You can use them for ID classes and also for logging implementations. They are a great feature with some very interesting use cases.

“Unused” type parameters can actually be very useful on inline classes. Take the following as an example.

The above defines a Key inline class which has an associated type parameter and inlines to a String. The Kotlin compiler claims this type paramter is unused but it can actually be used in function signatures.

Brian Norman

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store