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

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 make decisions, and sometimes in a defensive way. In this post I will give an overview of the options we have and the decisions we are provisioning. Setting the stage: Some introductory definitions Kotlin (as well as many other languages) has two kinds of metadata: modifiers (such as public, ope

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 calling top-level functions and properties. (more…)

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 versioning was concerned, and sometimes the users couldn't do what they needed to (especially when it came to inheritance); in M9 we discarded the annotations (for the time being), and introduced platform types, now anything could be done, but we lost (some) type-safety; in M11 we started bringing th

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 other DSL-like constructs. (more…)

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 the more Java-like @-based one: @Inject fun setFoo(foo: Foo) { ... } data class Foo volatile var bar: Bar = ... This change has some implications, though. (more…)

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, so that you could migrate your code before they are removed completely. (more…)

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 was to gather feedback on the term we proposed, namely "default object", and many of you rightfully stated in the comments that the term has a disadvantage: it is easily misread for "a default instance of the class". Now we are looking for a better term and need some more feedback... Update: than