Kotlin 1.0 Beta Candidate is Out!

Posted on by Andrey Breslav

We are happy to present Kotlin Beta Candidate. An official 1.0 Beta will be out soon. By now, the binary format is finalized, no major language changes are planned, and only a few changes in the standard library are coming.

In this post we describe the changes since M14, including

  • imports from objects,
  • new safer collection interfaces,
  • inlining for Java constants,
  • better support for Java statics,
  • and more.

Language changes

We are rolling out some breaking changes along with new important features.

Operators and infix functions

Since M14, Kotlin requires the operator modifier on functions that are used for operator overloading. From now on the same is required for infix functions:

operator Foo.plus(other: Foo): Foo { ... }

fun testPlus() = Foo() + Foo()

infix fun Foo.bar(other: Foo): Foo { ... }

fun testInfix() = Foo() bar Foo()

Now, we have relaxed this requirement for Java functions: any Java function with a suitable signature can be used as an operator, but not as infix.

Some operator names have been changed to avoid ambiguities:

  • we should now use unaryPlus and unaryMinus instead of just plus and minus for unary functions, i.e. -Foo() is now Foo().unaryMinus();
  • for delegated properties, getValue and setValue should be used instead of just get and set.

The Code cleanup action will help you migrate your code.

Also, operator signatures are now checked by the compiler at the declaration site. Some of these checks may be relaxed in the future, but we believe that what we have now is a pretty good starting point.

Imports from objects

Kotlin now supports importing individual members of objects by name (but not *-imports from objects):

import mypackage.MyObject.foo

val test = foo("...")

In this example we imported all members named foo from the named object mypackage.MyObject.

To import from companion objects of classes, we have to specify their full name:

import mypackage.MyClass.Companion.foo

Rich @Deprecated

We have been migrating a lot of code lately 🙂 So Kotlin’s @Deprecated annotation has become really powerful: not only does it require a message and allow to specify a replacement through ReplaceWith("..."), it also has a level now: WARNING, ERROR or HIDDEN.

  • WARNING is default and works as a normal deprecation: there will be warnings at call sites, and the IDE will strike it out,
  • ERROR is the same, but a compilation error is reported instead of a warning,
  • HIDDEN is what previously was @HiddenDeclaration: it simply makes this declaration invisible to clients at compile time.

Smart casts for captured local var’s

Smart casts now work even on local var‘s that are captured in lambdas, if they are not mutated in those lambdas:

var a: Any? = ...

val mapped = users.map {
    "${it.name}: $a"
}

if (a is String) {
    println(a.length) // This works now
}

Multiple main() functions in the same package

We can now define a main() function with standard signature in each file (with the exception of @file:JvmMultileClass). This is very useful when experimenting with code:

// FILE: a.kt
package foo

fun main(args: Array<String>) {
    println("a.kt")
}

// FILE: b.kt
package foo

fun main(args: Array<String>) {
    println("b.kt")
}

Varargs and spread operator

To recap: when calling a vararg function, we can use the spread operator that converts an array to a vararg:

fun foo(vararg args: String) { ... }

fun bar(vararg args: String) { 
    foo(*args) // spread operator
}

The semantics of the spread operator have been fixed so that it always guarantees that an array that foo sees will not be modified or observed by the “outside world”. We can assume that a defensive copy is made every time the spread operator is used (in fact, some optimizations may be implemented later to reduce memory traffic).

As a result, authors of Kotlin libraries can rely on the vararg arrays being safe to store without defensive copying.
NOTE: This guarantee is not fulfilled when Kotlin functions are called from java, because no spread operators are used there. This means that if a function is intended to be used from both Java and Kotlin, its contract for Java clients should include a note that the array should be copied before being passed to it.

“sparam” annotation target has been renamed to “setparam”

To annotate a setter parameter of a property, use setparam use-site target instead of sparam:

@setparam:Inject
var foo: Foo = ...

@UnsafeVariance annotation

Sometimes we need to suppress declaration-site variance checks in our classes. For example, to make Set.contains typesafe while keeping read-only sets co-variant, we had to do it:

interface Set<out E> : Collection<E> {
    fun contains(element: @UnsafeVariance E): Boolean
}

This puts some responsibility on the implementor of contains, because with this check suppressed the actual type of element may be anything at all at runtime, but it’s sometimes necessary to achieve convenient signatures. See more on the type-safety of collections below.

So, we introduced the @UnsafeVariance annotation on types for this purpose. It’s been deliberately made long and stands out to warn agains abusing it.

Miscellaneous checks and restrictions

Many checks were added, some of these restrictions may be lifted later.

Type parameter declarations. We decided to restrict the syntax of type parameter declarations so that all such declarations are consistent, so

  • fun foo<T>() is deprecated in favor of fun <T> foo():
  • All constraints on type parameters should occur either in “where” or inside “<…>”:

fun <T: Any> foo() {} // OK
fun <T> foo() where T: Serializable, T: Comparable<T> {} // OK

fun <T: Serializable> foo() where T: Comparable<T> {} // Forbidden

Dynamic type checks for arrays. Array element types are reified in Java, but their Kotlin-specific properties, like nullability, is not. So, we removed the special treatment of arrays that allowed checks like a is Array<String>, and now arrays work as all other generic classes: we can check for a is Array<*> and a cast like a as Array<String> is marked as unchecked. We added a JVM-specific function isArrayOf<T>() that check that a given array can contain elements of type T in Java:

    val a: Any? = ...

    if (a is Array<*> && a.isArrayOf<String>()) {
        println((a as Array<String>)[0])
    }

Delegated properties. The conventions for delegated properties now use KProperty<*> instead of PropertyMetadata in getValue and setValue:

fun Foo.getValue(thisRef: Bar, property: KProperty<*>): Baz? {
    return myMap[property.name]
}

Code cleanup will help you migrate.

Callable references. Some usages of :: are forbidden for now, to be enabled later when we implement bound references. Most notably, ::foo should not be used for now when foo is a member of a class. Only MyClass::foo should be used. References to members of objects are also unsupported temporarily (they will work as bound references too). We can use lambdas as a workaround for the time being.

If-expressions. We unified the semantics of if and when by requiring an else when if is used as an expression:

val foo = if (cond) bar // ERROR: else is required

Nothing-returning functions. When a function is known to throw an exception or loop forever, it’s return type may be Nothing, which means that it never returns normally. To make the tooling smarter, we require that such functions always have their return type specified explicitly:

fun foo() = throw MyException() // Must specify return type explicitly

fun bar(): Nothing = throw MyException() // OK
fun baz() { throw MyExcepion() } // OK
fun goo(): Goo { throw MyExcepion() } // OK

This is now a warning that will be promoted to error after we migrate our code with Code cleanup

Visibility checks were restricted so that, for example, a public declaration can not expose a local, private or internal type. Access to internal declarations is checked in the compiler as well as in the IDE;

See more here.

Collections

The major change in this version is that we have cleaned up collections and other core APIs so that, for example, size is now a property, and contains is type-safe: it takes E instead of Any?. This has been a major effort to make the library feel like Kotlin while keeping it compatible with Java. There’s quite some compiler magic behind it, but we are pleased with the result.

Example:

val strs = setOf("1", "abc")

if (1 in strs) { // 'strs' is a set of strings, can't contain an Int
    println("No!")
}

Analogous code works in Java, because Set<E>.contains (which in is compiled to) takes Object, not E, the element type of the set. This has proven to be error-prone, so we decided to make Kotlin collection interfaces safer (while keeping full compatibility with Java collections). As a result, our contains takes an E, and the example above is incorrect in Kotlin.

At the moment the Kotlin compiler reports a deprecation warning on in in the example above, because we have provided transitional extension functions in the standard library to help everyone migrate, but soon this will be an error. Code cleanup is our friend here: it will replace 1 in strs with strs.containsRaw(1). containsRaw is a new function in the standard library that we can use when we really need the Java-like behavior: we can check membership of any object in any set by using containsRaw.

Bottomline:

  • Collection.contains, Map.get and some other collection methods are now safer;
  • We can use containsRaw, getRaw, etc to get the untyped behavior;
  • Collection.size, Array.size, String.length, Map.Entry.key etc are now properties;
  • List.remove(Int) has been renamed to removeAt(int) to avoid clashes with List<Int>.remove that removes by item, not by index;
  • Code cleanup will migrate all the code.

All normal Java collections work without changes: the compiler knows how to find a “property” size on a java.util.ArrayList.

Java interop

There have been many important changes that concern how Kotlin declarations are visible from Java and vice versa.

Inlining constants defined in libraries

From now on we inline Java constants (public static final fields of primitive and String types) that come from libraries. This will help Android developers that have been suffering from API incompatibilities:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) { ... }

Will now work on any version on Android runtime (used to crash on runtimes younger than Lollipop).

Smaller runtime

We are only starting there, but the foundation has been laid for the work on reducing the size of the kotlin-runtime library. It is now only 200K smaller than it was in M14, but there are more things we’ll do to make it smaller (and it won’t break compatibility).

Static methods, fields and classes

Kotlin is now very friendly to Java statics:

  • we can use inherited nested classes, static methods and fields from Java classes inside their Kotlin subclasses;
  • we can access inherited Java static methods and fields through subclass name: SubClass.SUPER_CLASS_CONSTANT;
  • we can access members of companion objects of superclasses from within Kotlin subclasses;
  • but the only qualified name a class can be accessed by is its canonical name, i.e. we can’t say SubClass.SupersInnerClass.

This closes many issues we used to have with big inheritance-based frameworks like Android.

Interface inheritance rules are compatible with Java 8

To make Kotlin future-proof, we added some requirements that comply with the Java 8’s ones, to be able to later compile function bodies in Kotlin interfaces to Java default methods.

In some cases it leads to Kotlin requiring more explicit overrides than before, and, sadly, methods of Any can’t be implemented in interfaces any more (this wouldn’t work in Java 8).

Side note: the default implementations of interface methods are accessible from Java through as static members of MyIntf.DefaultImpls.

More convenient getter names for booleans

When a property in Kotlin is, for example, named isValid, its Java getter will now be isValid() and not getIsVaild().

@JvmField and objects

We have made the strategy for generating pure fields (as opposed to get/set pairs) more predictable: from now on only properties annotated as @JvmField, lateinit or const are exposed as fields to Java clients. Older versions used heuristics and created static fields in objects unconditionally, which is against our initial design goal of having binary-compatibility-friendly APIs by default.

Also, singleton instances are now accessible by the name INSTANCE (instead of INSTANCE$).

We had to prohibit the usage of @JvmField in interfaces, because we can’t guarantee proper initialization semantics for them.

Int is Serializable

Now the type Int and other basic types are Serializable on the JVM. This should help many frameworks.

No “package facades”

Classes like KotlinPackage etc are gone. We have finished the transition onto the new class-file layout, and the previously deprecated “package facades” are now removed. Use FileNameKt and/or @file:JvmName (with the optional @file:JvmMultifileClass).

Internals are now mangled

Since Java doesn’t have internal visibility (yet), we had to mangle the names of internal declarations to avoid unexpected clashes in overrides when we extend a class from another module. Technically, internal members are available to Java clients, but they look ugly, which is the minimal price we could pay for predictability of library evolution.

Other deprecations and restrictions

  • @Synchronized and @Volatile are not applicable for abstract declarations;
  • As the final step of getting rid of external annotations, @KotlinSignature is deprecated and will be removed;
  • Generic types whose arguments contains Nothing are compiled to raw Java types now, since Java doesn’t have a proper counterpart of `Nothing;

IDE Changes

  • Now Parameter Info works almost everywhere, including brackets, this and super calls

  • Completion now supports callable references (after ::)

  • We can easily generate equals() and hashCode() methods

  • Also the IDE helps generate Secondary Constructor based on superclass constructor and currently uninitialized properties

  • Support for configurable “import *” for importing static members of Java classes and enums

  • The last but not least, unit testing experience is much smoother now. List of improvements: “Create Test” action, tests are runnable via gutter icons, navigation between tests and test subjects (⇧⌘T/⇧^T) and also quickfixes to add dependencies on JUnit and TestNG when needed

Libraries

Thanks to the aforementioned changes in spread operator semantics, listOf() now is more efficient, because is doesn’t have to defensively copy the input array.

Regex API has been improved, so that we can now say regex in string instead of regex.hasMatch(string).

Tools

  • Compiler daemon is now enabled by default in the IDE
  • Parallel Compilation of Independent Modules is now supported in the daemon
  • Options related to external annotations are removed from tools like Maven and Gradle

Installation

Kotlin is bundled with IntelliJ IDEA 15 RC. For IntelliJ IDEA 14, please update through the Plugin Manager.

Have a nice Kotlin!

Comments below can no longer be edited.

71 Responses to Kotlin 1.0 Beta Candidate is Out!

  1. Krtko says:

    October 22, 2015

    Looks good! I like that you guys are focused on reducing the size of the Kotlin runtime!

    What’s the current plan/roadmap for compiling to JavaScript?

    I hope you guys can eventually figure out how implement native inlined constants into your rolling compilation.

    Thanks for making Android programming awesome 🙂

    • Jayson Minard says:

      October 22, 2015

      It’s been stated before that futher work on JavaScript support will be after 1.0. So its a great question to ask after 1.0.

    • Andrey Breslav says:

      October 22, 2015

      The plan for JavaScript is that it has to wait until we are done with 1.0 for JVM, and then we’ll get back to it.

  2. Salomon BRYS says:

    October 22, 2015

    Congratulations, guys ! Kotlin 1.0 is in sight, that’s tremendous news 🙂
    All changes announced look good to me 🙂
    I’m really excited about Kotlin finally reaching 1.0 🙂
    On a side note : I’d like to know what will the future hold for Kotlin once it has reached 1.0. Not in terms of features but in term of development (pace, involvment, etc.). I guess that’s a story for another time.
    Congrats again to everybody at JB 😉

  3. Jayson Minard says:

    October 22, 2015

    Some libraries updated for this release of Kotlin:
    Jackson-module-kotlin 2.6.3-1
    Injekt 1.8.0
    Klutter 0.8.0
    Kovert 0.6.0
    Kovenant 2.9.0

  4. Olivier Binda says:

    October 22, 2015

    it’s nice to get more safety for maps and sets…
    Got bitten by that a few times and it used to take time to find where the bugs came from

  5. Konstantinos Paparas says:

    October 22, 2015

    That’s really wonderful news 🙂

  6. Pedro Veloso says:

    October 22, 2015

    Love it! Love the better support for Android as well 🙂
    Keep up the good work.

  7. Eugene Krivenja says:

    October 22, 2015

    I moved my Android project to Kotlin 1.0.0-beta-1038 and faced with an issue. On emulator with Android before KitKat the install fails with an error:
    – Command line – Failure [INSTALL_FAILED_DEXOPT]
    – Jenkins – com.android.ddmlib.InstallException: INSTALL_FAILED_DEXOPT

    Looks like some bytecode generation issue?

    • Eugene Krivenja says:

      October 22, 2015

      Just checked on device with Android 4.1.2, same issue.

      • yanex says:

        October 22, 2015

        Can you please create a small project in which the bug can be reproduced? You can send it to yan.zhulanow[at]jetbrains.com.

      • yanex says:

        October 23, 2015

        I was able to reproduce the bug. We will investigate it.

        • Harris says:

          October 24, 2015

          I have the same issue, It’s fix now? I can’t install kotlin app on Meizu’s Phone. I’m using 1.0.0-beta-1038, I need help urgent.

          • Andrey Breslav says:

            October 25, 2015

            We will publish a fix soon. Meanwhile you can roll back to the previous version of Kotlin.

        • Eugene Krivenja says:

          November 2, 2015

          I see, it is fixed in 1.0.0-beta-1103, thank you!

    • dynasty says:

      October 23, 2015

      I’ve encountered this problem too…
      And I also encountered with
      INSTALL_FAILED_UID_CHANGED

      • drakeet says:

        November 2, 2015

        INSTALL_FAILED_UID_CHANGED too!!!
        Please fix it QAQ…

        • Andrey Breslav says:

          November 2, 2015

          Must be fixed in 1.0.0-beta-1103, check it please

    • Omar Miatello says:

      October 23, 2015

      I’m trying to rollback to 0.14.451 but I can’t find the right plugins

      https://plugins.jetbrains.com/plugin/6954?pr=androidstudio
      https://plugins.jetbrains.com/plugin/7717?pr=androidstudio

  8. mzgreen says:

    October 22, 2015

    What about better support for Annotation Processing?

    • Andrey Breslav says:

      October 23, 2015

      What use cases do you have in mind?

      • mzgreen says:

        October 23, 2015

        Fully supporting Dagger 2 (as far as I know currently it’s not possible to use generated classes in Kotlin), supporting other libraries like Android’s DataBinding or ButterKnife.

  9. OvermindDL1 says:

    October 23, 2015

    I am confused why kotlin exists when scala has near identical syntax, has been around longer, can seem to do everything that kotlin can as well as a tremendous amount more. Can anyone clarify?

    • Krtko says:

      October 23, 2015

      https://kotlinlang.org/docs/reference/comparison-to-scala.html This seems like a pretty fair answer to your question

    • Jacob Zimmerman says:

      October 23, 2015

      Watch just about any of the videos they have out there. They have some beefs against Scala.

    • Dmitry says:

      October 23, 2015

      Kotlin has much better Android support than Scala. And for me that is a killer feature.

    • Steven Holmes says:

      October 27, 2015

      Wildly different philosophies. Compared to Java, Scala is all about power, doing things that Java cannot do. In that way, it is philosophically similar to groovy, albeit with an impressively powerful (and complex) type system. It can do almost anything, as you’ve already noted. Simplicity, conciseness, performance, java interoperability, backwards compatibility, library size, and tool support are all afterthoughts in Scala, or at least secondary to powerful language features. Kotlin is much more pragmatic. In Kotlin these things are first class concerns, and powerful language features are balanced against, and sometimes secondary to, these things.

  10. Kotlin 1.0 Beta Candidate is Out! | JAVA says:

    October 23, 2015

    […] by javinpaul [link] [1 comment] Full article:Kotlin 1.0 Beta Candidate is […]

  11. Mykhailo says:

    October 23, 2015

    Great news!
    Special thanks for relaxing “operator” restriction for java methods.

  12. Matt Freeman says:

    October 23, 2015

    Congrats. How many full-time developers at Jetbrains are currently working on Kotlin and its ecosystem? Do you have any internal buy-in – i.e. are parts of Intellij being written in Kotlin (I am aware externally that parts of Cursive Clojure are)? Is the Kotlin support 1st class in IntelliJ – i.e. comparable experience to that of Java?

    • Andrey Breslav says:

      October 23, 2015

      We have a team of over 20 developers. Parts of IntelliJ IDEA and other products are written in Kotlin, some of them have >90% Kotlin code in them.

      I believe that Kotlin IDE support is 1st class, and to my mind is is totally comparable to that of Java (it’s a subjective qualitative assessment), while it definitely has fewer features than Java support that started at least 10 years earlier.

      • Max M. says:

        October 24, 2015

        Is there any chance to get something like a paper or a blog with some numbers?
        I’m asking because having somewhat “real numbersW would greatly improve our (developers) standpoint against our higher ups / clients / product owners / … to justify the use of kotlin in production.

        Like in “Hey, the stuff we build stuff in IS build in kotlin!”

  13. Beta Candidate für Kotlin 1.0 erhältlich - JAXenter says:

    October 23, 2015

    […] Machern zufolge keine mehr geplant. Im Vergleich zum letzten Meilenstein haben sich im Rahmen des Beta Candidate erneut teils beträchtliche Neuerungen […]

  14. Dex Wood says:

    October 23, 2015

    I was recently using a sealed class, and I was using the equality of its child classes. Since data classes can no longer inherit from other classes, you must override equals, hashCode, and toString to get a nice behavior of those classes. I also saw an example of someone implementing a Maybe class where the Just method was a data class for comparison and representation at https://medium.com/@octskyward/kotlin-fp-3bf63a17d64a#.806i8gq9r

    Is there a way to somehow allow data classes to inherit sealed outer classes? Maybe have the child classes of a sealed class get a nice hashCode, toString, and equals implementation. What are some other use cases of sealed classes that would cause problems for this idea? This use of sealed classes seems like it will be very common.

    My use of the code follows:


    enum class RelayState { COOLING, HEATING }
    sealed class PowerState {
    data class ON(val relayState: RelayState) : PowerState()
    object OFF : PowerState()
    }

    vs

    enum class RelayState { COOLING, HEATING }
    sealed class PowerState {
    class ON(val relayState: RelayState) : PowerState() {
    override fun equals(other: Any?): Boolean {
    if (this === other) return true
    if (other !is ON) return false

            if (relayState != other.relayState) return false
    
            return true
        }
    
        override fun hashCode(): Int {
            return relayState.hashCode()
        }
    
        override fun toString(): String {
            return "ON($relayState)"
        }
    }
    
    object OFF : PowerState()
    

    }

    • Andrey Breslav says:

      October 24, 2015

      Thanks for the use case. We’ll probably relax some limitations on data classes

  15. Michel says:

    October 23, 2015

    Finally have you made a decision concerning marking result expressions ?
    “^” or “<-” ?

    • Nikolaos Papadakis says:

      October 24, 2015

      Hi, I’m wondering as well if marking result expressions will make it into 1.0 or it was decided that it will be a future feature?

      Thanks

      • Andrey Breslav says:

        October 25, 2015

        Definitely not 1.0, most probably not a future feature either

    • Andrey Breslav says:

      October 25, 2015

      Yes, we considered many points, and decided that it was impractical to require prefixes on result expressions

  16. Grdykopląs Namorzyn says:

    October 24, 2015

    Something very strange is happening after last update. The IDE highlights error in places where compiler doesn’t complain. When I correct the errors according to IDE, the compiler won’t compile.

    Example functions (in a clas derived from javaList)
    IDE: size() cannot be invoked as a function, Compiler: Function invocation size() expected
    IDE: assumes that List.remove(int) is actually List.removeAt(int) (?!), Compiler: unresolved reference removeAt

    So I have either compilable code with lots of error highlighted or uncompilable code that is shown as OK in Idea…

    • Andrey Breslav says:

      October 25, 2015

      Looks like either the standard library was not updated (e.g. you have different versions in the IDE plug-in and in Gradle), or IDE caches got stuck (in this case *File -> Invalidate Caches -> Invalidate and Restart)

      • Grdykopląs Namorzyn says:

        October 25, 2015

        Which one is new then in my case? Library or plugin? Invalidating cache didn’t help.

        • Andrey Breslav says:

          October 25, 2015

          How is your project configured? Do you use Gradle? If yes, you can see the library version in your build file. And the version of the plug-in can be seen in Plugin Manager

  17. Links of the Week, W44 2015 | One More Game-Dev and Programming Blog says:

    October 25, 2015

    […] Kotlin 1.0 Beta Released. […]

  18. Cuper says:

    October 26, 2015

    May I ask why import object.* is not allowed?

    Since Kotlin plugin can’t add import object.A automatically, we still have to write import statements one by one for every imported object methods and variables.

    • Roman Belov says:

      October 26, 2015

      import object.* leads to importing hashCode, equals et al. Mostly it would be very confusing.
      And most likely special intention action will be implemented for auto imports from objects.

    • Andrey Breslav says:

      October 26, 2015

      Objects may inherit things from supertypes, e.g. equals()/hashCode() will be imported every time you ‘*’-import from an object, we decided that this would be too confusing. The IDE should be fixed soon

  19. Viachaslau says:

    October 27, 2015

    How about also add autoconversion between simple types? int -> float, float -> double
    it’s a little anoing
    fun foo(x:Float)

    foo(1) //error
    fii(1f) //no error

    • Andrey Breslav says:

      October 27, 2015

      Unfortunately, this is incompatible with the fact that we do not distinguish between primitive types and classes

    • Grdykopląs Namorzyn says:

      October 27, 2015

      And I think it’s a bad idea, too. I just hate how many errors I get in Java because of automatic conversions. I’ve never grasped what is converted to what. Kotlin way seems much better,

  20. Cuong says:

    October 28, 2015

    Why do we need * prefix to be able to pass arrays as varargs? I am learning Kotlin by solving problems in Kotlin Koans and I find it difficult to express my solution for _29_OperatorsOverloading problem[1]. With my extension functions, I am unable to make Kotlin evaluate: today + YEAR * 2 + WEEK * 3 + DAY * 5

    fun MyDate.plus(vararg timeIntervals: TimeInterval): MyDate {
    return timeIntervals.fold(this, {date, timeInterval -> date.addTimeIntervals(timeInterval, 1)})
    }

    fun TimeInterval.times(num: Int): Array {
    return Array(num, {this})
    }

    [1] – https://github.com/JetBrains/workshop-jb/blob/master/src/iii_conventions/_29_OperatorsOverloading.kt

    • Andrey Breslav says:

      October 29, 2015

      Why we need the spread operator: because, for example, if a function takes vararg of Any, then any array may be either an element of a vararg or a container for all vararg elements:

      fun foo(vararg elements: Any) { ... }
      
      fun test(a: Array<Any>) {
          foo(a) // should foo receive an array whose only element is a: [a] or a itself?
      }
      
      • Cuong says:

        October 29, 2015

        I see. Thank you for your explanation and example. I am sorry for post the same question twice.

  21. Cuong says:

    October 29, 2015

    My previous comment got removed for some reasons so I ask again. Why do we need * prefix to pass arrays as varargs?

  22. Matt says:

    October 29, 2015

    I would love to see the spread operator for maps for named arguments.

    • Andrey Breslav says:

      October 29, 2015

      Can’t be done in a static language

      • Matt says:

        October 29, 2015

        That makes me sad. Still love kotlin so far. Looking forward to the finalized 1.0 release for my production android projects.

  23. Grdykopląs Namorzyn says:

    October 29, 2015

    I think I’ve found an issue with 1.0 deleteAt(Int) vs delete(int) magic, filled it under KT-9824

  24. Guest says:

    October 31, 2015

    This might not be the correct place to ask this: but how can I use KTypes and such to distinguish class types and such?

    Lets say I get a function and loop through its parameters. Each KParameter has a KType, which should correspond with a class but without that class object itself I cant necessarily check inheritance and others, whats the point?

    • Andrey Breslav says:

      October 31, 2015

      The reflection API is not complete at this point, more information, such as detailed type information, will be added later. As a workaround you could use Java reflection now (there’s an API to convert a Kotlin reflection object to a Java reflection object).

  25. drakeet says:

    November 2, 2015

    Can not install android apk file below Android 4.4

    Failure [INSTALL_FAILED_UID_CHANGED]

    • Andrey Breslav says:

      November 2, 2015

      Must be fixed in 1.0.0-beta-1103, check it please

      • Viktor Isakov says:

        November 2, 2015

        I tried to install a simple android app on fresh emulator with android 4.1 with a new kotlin v.1.0.0-beta-1103, but had the same INSTALL_FAILED_UID_CHANGED problem.

        • Andrey Breslav says:

          November 2, 2015

          From what I see here, it may not be connected to Kotlin.

          Could you try one of these?

        • Eugene Krivenja says:

          November 2, 2015

          Looks like your AVD is not so “fresh” 🙂 Wipe out user data and the error will be gone.

          • Viktor Isakov says:

            November 2, 2015

            Factory reset and removing /data/data/ folder work, but how about updating application?

        • Eugene Krivenja says:

          November 2, 2015

          Once app install failed with error INSTALL_FAILED_DEXOPT, you must reboot the device before install valid APK again, otherwise you will see INSTALL_FAILED_UID_CHANGED error.

  26. Jan Kovar says:

    November 3, 2015

    Hi,
    can you please check this issue?
    https://youtrack.jetbrains.com/issue/KT-9758
    Issue appeared in beta candidate and it appears in 1.0.0-beta-1103 as well.
    I know that Javascript compilation is not your priority right now but hope it get resolved in 1.0 🙂
    Thanks