Post-1.0 Roadmap

Language Design
1

Now that 1.0 is out, will there be a roadmap for what comes next, and what release cycle we can expect? In particular, I’d love to hear about the relative prioritization of the following features:

  • async-await
  • type aliases
  • improved Java 8 support
  • Java 9 support (esp. Jigsaw)
  • Javascript backend
  • improved interactive experience (cf. Scala Worksheets)
  • complete language specification

I’d also be interested in the current assessment of the following potential features, all of which have been discussed at some point:

  • externally implemented interfaces (cf. Swift)
  • nullability checks for core parts of the Java standard library
  • union and intersection types (cf. Ceylon, Dotty)
  • ability to write code that runs both on JVM and Javascript platforms
  • power asserts (cf. Groovy)
  • some form of macros

Keep up the good work on making Kotlin the best practical JVM language (and more). I’m looking forward to what’s ahead.

5 Likes
2

This one is probably best done as an upstream OpenJDK project. It’s not Kotlin specific.

They’re already working on this at the moment, so I guess it’s high priority for them.

I believe this was ruled out relatively recently.

Andrey did an interview where he said Java 8 support was a high priority post 1.0.

3

There is only one thing that I’m hoping for in 1.1: Please fix all those pesky exceptions in the IDE plugin! There hasn’t been a single version of the plugin that I can remember that survived the first five minutes without throwing an exception.

1 Like
4

It is Kotlin specific in that:

  • Kotlin supports non-nullable types (unlike Java).
  • Kotlin’s standard library is not comprehensive by design, hence most JVM apps and libraries written in Kotlin will presumably need to make significant use of the Java standard library (unlike Scala or Ceylon code).
  • Kotlin goes further than any other language in providing the best possible Java interoperability experience.
  • Java isn’t going to address this problem anytime soon.

My question is what the goals are in terms of sharing code between both platforms, considering that Kotlin’s standard library is less comprehensive than Scala’s and Ceylon’s by design.

Do you have a link to support that claim? My impression is that adding support for some form of compile-time meta-programming hasn’t been ruled out.

5

By “not Kotlin specific” I meant that Java devs can benefit from nullability annotations as well.

“Java isn’t going to address this problem anytime soon” … why do you say that? Did Mark Reinhold rule out a nullability annotations project? The JDK is annotated in various ways already, a project to add more annotations doesn’t seem unrealistic.

Not off hand, it’s something that I recall reading in various places like Slack, articles, etc. Kotlin’s current support for extending the language is inline functions. I’d expect/hope for them to be made more powerful before alternative ways to do such things is introduced (e.g. flow typing through inlined calls would be useful).

6

I believe it was JSR 305 that wanted to address nullability checks. It never got very far and never got incorporated into the JDK itself. There are a number of different interpretations of nullability: IntelliJ, Eclipse, Google (in Guava) and FindBugs. Having worked in a mixed IDEA/Eclipse project which used null checks, I can say that the lack of a common understanding is really annoying. Eclipse checks report different problems as IDEA checks do. There is a number of corner cases that a developer needs to handle without the support of the IDE to be compatible to both.

There must be a common understanding before there can be any effort to annotate the JDK. The result of that effort may not even be compatible with Kotlins understanding of Nullability. As much as I would like to see that, I am not aware that this is on Oracle’s roadmap.

7

JSR-305 has been dormant for years, Java 10 is about 4 years away, and I haven’t heard of any plans to address this problem.

Inline functions are indeed a good start.

8

I would love to see the ability to return multiple results. I think Swift has this.

(valA,valB) = functionC()

I have the often and defining a structure is overkill

9

Umm, it already exists. https://kotlinlang.org/docs/reference/multi-declarations.html

10

OMG. How did I miss that. Soo much awesome-sauce

11

Just to be clear: Even though most examples use data classes to explain destructuring, you do not have to use them! You can destructure any Kotlin object that follows the convention and declares the appropriate functions:

class SomeFancyData(val x: Int, val y: Int) {

    operator fun component1() = "a".repeat(x) + "b"
    operator fun component2() = (y + x) * 42
}

You can then use it as:

val d = SomeFancyData(2, 3)
val (a, b) = d

You can have fun with that in very weird ways:

private fun divisors(n: Int): List<Int> {
    val result = mutableListOf<Int>()
    for (i in 1..n) {
        if (n % i == 0) {
            result += i
        }
    }
    return result
}
operator fun Int.component1():Int = 1
operator fun Int.component2():Int? {
    val divs = divisors(this)
    return if (divs.size >= 2) divs[1] else null
}
```

If you use this like that:
```
val (d1, d2) = 5
```
It will give you the first two divisors of the number 5. But as you can see, extending this idea to find the first 150 divisors would keep you busy with copy & paste.

Unfortunately, destructuring does not work for Java classes because you can't declare the the corresponding operator functions there. Well, unless you add them as extension functions on the Kotlin side.
12

Still hoping for an answer from the Kotlin team.

13

Another feature of interest for me is custom string interpolation. sql"select a from b where c = $d" and similar constructions.

15

Some preliminary plans and priorities:

async-await

Requires some investigation to estimate the effort required to implement it. Investigation is in progress.

type aliases

We think it’s a very important feature, planning to start working on it soon

improved Java 8 support

If you mean accessibility of streams API, then it’s on the roadmap for 1.1 too.

Java 9 support (esp. Jigsaw)

We aim at releasing Jigsaw support about the same time as JDK 9 will be released. Preview versions will be available earlier.

Javascript backend

Actively working on it.

improved interactive experience (cf. Scala Worksheets)

This is pretty vague, but we are working on some things in this direction

complete language specification

In progress

On the second part though:

externally implemented interfaces (cf. Swift)

Costly at runtime, some experimentation required to figure out whether invokedynamic can help us there.

nullability checks for core parts of the Java standard library

If you mean annotating the JDK, this is possible, but would require a significant effort.

union and intersection types (cf. Ceylon, Dotty)

We are still short of good use cases for these features.

ability to write code that runs both on JVM and Javascript platforms

We plan to support it, it’s a major feature on the JS roadmap (no promise of full JDK available on JS, though)

power asserts (cf. Groovy)

Interesting feature, but not very clear whether we can implement it soon

some form of macros

Macros = user code executed at compile time. It’s very unlikely that we’ll add macros to Kotlin.
A powerful compiler plugin API that allows code transformations — very probably.

1 Like
16

How about the ability to have sealed data classes, or inheritance between data classes ?

17

We are planning to support allowing data classes to inherit from sealed classes.

18

Hell yeah !!!
Is it planed for 1.1 or later ?

19

Most likely 1.1, we’ll see

20

I really would like to see a “Develop with Pleasure” release for Kotlin for 1.1: IDEA does, refactors, and analyzes virtually everything you can think of in Java code. Even though Kotlin is better as a language, its tool support still is the new kid on the block.

I’m not into the details enough to know whether Java 8 bytecode (e.g. for lambdas) would be a performance/memory improvement over the current implementation. I’m personally not interested in Javascript at all.

About the JDK Nullable annotations: What’s the current state of this effort? Would it be reasonable to crowd source this (e.g. as a GitHub project)? That would be something that would be helpful for Java code as well. And - I do know about the problems associated with this. Changes in Nullability between different versions of the external annotations causing compilation errors is one of them (you could make it an IDE warning but not a compiler error, though). Just a thought.

21

We’ve had enough trouble with this in the past to dive into it head-first again. So, we’ll need to work out a really detailed plan before we do anything, and it doesn’t seem like a too high-priority feature ATM