Category Archives: Language design

Thank you all for the feedback we got on the previous call! Here comes another round of changes and adjustments. Your opinions and use cases are welcome.

As mentioned before, we are wrapping up with the language design, and this post is a head-up for the upcoming changes + request for your feedback.

While M13 is approaching, we are planning a little ahead. This is a request for feedback on some future changes in Kotlin. We want to deliver Kotlin 1.0 rather sooner than later, and this makes us postpone some design choices … Continue reading →

This is another heads-up and a call for feedback. We have been discussing options regarding Kotlin’s annotation syntax for quite some time already, rolling out experiments, gathering feedback. As we are finalizing the language now, many pain points that we … Continue reading →

Kotlin has had top-level functions and properties from day one. They are very convenient in many cases: from basic utilities to extensions for standard APIs. But Kotlin code is not the only client, and today I’m going to explain how … Continue reading →

Our battle for combining null-safety and Java interop has been a long one already: we started off treating all Java reference types as nullable, and it was too inconvenient; then we employed external annotations to specify nullability, created KAnnotator, but … Continue reading →

Kotlin M12 will likely bring another change that is crucial for implementing a useful reflection library for Kotlin. In short, we are going to unify FunctionX and ExtensionFunctionX to be represented in the same way at runtime, but it will … Continue reading →

Enum Syntax Currently the syntax for enums with non-trivial constructors is kind of monstrous:

There are two more items on the language cleanup list: backing-field syntax and static type assertion operator.

Kotlin’s syntax for annotations was inspired by C#, which surrounds them with square brackets:

But brackets are precious for a language designer, and we would really like to use them later for something else, so we are considering changing … Continue reading →