Upcoming Feature Deprecations

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.

Required Classes

Some of you might have heard of this feature: traits in Kotlin can “extend” classes (we actually use the term “require”).

Technically it means that when a class extends such a trait, it must (directly or indirectly) extend the required class as well. This feature has very few use cases, so we are deprecating it.

Captured Type Parameters

When a generic class Outer has an inner class Inner, Java allows us to use generic parameters of Outer inside Inner:

Although very logical, this feature also has rather few use cases, and current implementation we have in Kotlin requires a lot of work before it is production quality. So, we are going to forbid this, and maybe implement it in later releases of Kotlin.

If you happened to use this (which is very unlikely), your workaround is rather straightforward:

Covariant Specialization for Supertypes

I’m really skeptical about anyone even knowing that this feature exists :)

The current compiler allows a class/trait to have more than one (indirect) supertype of the same class, if one of them is a subtype of the other:

Note that List is co-variant in Kotlin.

Although, again, logical, this has almost no use-cases, to our knowledge, but supporting this involves a lot of compiler magic and breaks Java interop right and left, so we are going to drop this.

More Deprecations Coming

We’ll share some more plans of this sort soon. And will keep you updated on the features we are implementing now.

About Andrey Breslav

Andrey is the lead language designer of Kotlin at JetBrains.
This entry was posted in Language design. Bookmark the permalink.

18 Responses to Upcoming Feature Deprecations

  1. A wise approach to reduce “compiler magic” as it might drain resources from features that are actually useful. It’s also good to keep conceptual proximity to Java (List is not a subtype of List due to JVM-level type erasure).

  2. Salomon BRYS says:

    I understand the need for a clean code base in the compiler as well as the need for a “simple” language, but I found the “required classes in traits” feature to be suprisingly useful. I have used it in several places in my project.
    Could you share more insight as to why you are dropping it? Is it only the lack of use or are there some “compiler magic” that will be better off the compiler? Also, any advice to update a code that is using this feature ?

    • It requires substantial compiler magic, yes. What are your use cases?

      • Maxim Shafirov says:

        I once used it to provide a method with default implementation to a hierarchy, where base class is out of my reach.

      • Salomon BRYS says:

        Here’s my setup.

        trait KContext {
        public val context: Context

        I have a lot of KContext extension methods. It allows me to do a lot of context dependent operations regardless of whether I am in an Activity, a Fragment, a ViewHolder, a Service, etc.

        trait KActivity : Activity, KContext {
        override val context: Context get() = this

        Now, when I declare a new Activity, I can do:

        public class MyActivity : FragmentActivity(), KActivity

        Whether this activity is a FragmentActivity, an ActionBarActivity, or any other subclass of Activity, it will work.

        The same goes of course for Fragment, ViewHolder, Service, etc.

        I haven’t found a correct way to do this without the “required classes in traits” feature.

        • If you drop the required class, all you need is cast this to Activity, or even just Context:

          Not as type-safe, but it’s very little sacrifice, I think.

          • Salomon BRYS says:

            Won’t that induce a runtime overhead each time context is called as such casts are verified by the VM ?

            • Well, first of all, this is exactly how required classes work (all other ways would involve black magic: scary and unreliable).

              Then, cast is not a very expensive operation: how many times is this going to be executed?

          • Salomon BRYS says:

            I don’t know how many times, but if it is the way the compiler already does this, then it won’t induce any additional overhead 😉
            Still sad this feature is going away, though. I liked it 😉

        • Damian Petla says:

          For me “requied class” is also one of the coolest features. I am creating dedicated modules for some classes and I can access their methods and properties from trait. It kind of allows to inherit from muliple classes since traits provides implementation not just function declarations. I can understand this feature deprecated only if its a performance issue or another hell under the hood, otherwise please consider keeping it or maybe improve.

          • Could you share some examples of your modules?

            • Damian Petla says:

              Here is an example https://gist.github.com/damianpetla/f35278857667b3b20f23
              On second thought I could create a property GmailAuthenticator in MainActivity and pass instance of Activity to authenticator but I like the way it looks now.
              I also like about Kotlin that it is more restricted than java, restricted classes are great example. I can create traits that can be implemented only by classes I point.
              Anyway, if keeping it is an issue lets drop it. Btw, love Kotlin :)

          • Salomon BRYS says:

            I agree.
            Better type safety than Java is one of Kotlin’s main promise.
            Using casts will surely allow to “do the same” but we will lose in both readability and type safety.
            So, as Damian says, please consider keeping it or maybe improve.

  3. Mohammad Shamsi says:

    Those mentioned in the blog, seem really good candidates for clean up. especially “Required Classes”.

Comments are closed.