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. (more…)…

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. (more…)…

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 we don't have enough confidence about. Today let's discuss data classes. …

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 used to postpone are surfacing. We have to …

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 we are planning to improve on the Java interop when it comes to ca…

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 the whole thing was too fragile when v…

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 not affect our ability to create type-safe builders and othe…

Enum Syntax Currently the syntax for enums with non-trivial constructors is kind of monstrous: enum class Message(val str: String) { ERROR : Message("This is an error") WARNING : Message("This is a friendly warning") DEBUG : Message("Ignore this") } (more…)…

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

Kotlin's syntax for annotations was inspired by C#, which surrounds them with square brackets: fun setFoo(foo: Foo) { ... } 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 the annotation syntax to th…

As we are finalizing the language design, many things have to be cleaned up, and among these are features that were initially designed and (often partly) implemented, but turned out not to be worth the trouble supporting them. In the upcoming M12 milestone, we are going to deprecate such features, …

In the previous post I explained the rethought design of what used to be called "class objects": they are now more uniform with normal nested objects, have names (name may be omitted, but a default one will be used by the compiler), and we can write extensions to them. One of the goals of that post…