The documentation for Kotlin is now located on the new site. This page is kept for historical reasons

Skip to end of metadata
Go to start of metadata

The documentation for Kotlin is now located on the new site. This page is kept for historical reasons

Functions in Kotlin are declared with the fun keyword:

fun double(x : Int) : Int { 
  return x * 2 

A function call goes in the traditional way:

val two = demo(1)

See also Infix calls and Operator overloading.

Single-expression functions

If a function just returns a value of a single expression, one can specify its body after '=' and with no return statement:

fun double(x : Int) : Int = x * 2

In this case, it is allowed to omit the return type annotation, and the type will be inferred from the expression on the right-hand side:

fun double(x : Int) = x * 2

Unit-returning functions

If a function does not return any useful value, its return type is Unit. Unit is a type with only one value — Unit.VALUE. This value does not have to be returned explicitly:

fun printHello(name : String?) : Unit { 
  if (name != null) 
    print("Hello, $name!") 
    print("Hi there!") 
  // We don't need to write 'return Unit.VALUE' or 'return', although we could 

Neither has the Unit return type to be specified explicitly:
If a function has a block body (in curly braces, not after '=') and returns Unit, one can omit the return type annotation:

fun printHello(name : String?) { 

Local functions

Kotlin supports local functions, i.e. one can define a function inside a function:

fun dfs(graph : Graph){ 
  fun dfs(current : Vertex, visited : Set<Vertex>) { 
    if (!visited.add(current)) return 
    for (v in current.neighbors) 
      dfs(v, visited) 
  dfs(graph.vertices[0], HashSet()) 

Local functions can "see" local variables of outer functions (i.e. the closure), so we can have our visited set as a local variable, not a parameter to always pass around:

fun dfs(graph : Graph){ 
  val visited = HashSet<Vertex>() 
  fun dfs(current : Vertex) { 
    if (!visited.add(current)) return 
    for (v in current.neighbors) 

Local functions can even return from outer functions using qualified return expressions:

fun reachable(from : Vertex, to : Vertex) : Boolean { 
  val visited = HashSet<Vertex>() 
  fun dfs(current : Vertex) { 
    // here we return from the outer function: 
    if (current == to) return@reachable true 
    // And here -- from local function: 
    if (!visited.add(current)) return 
    for (v in current.neighbors) 
  return false // if dfs() did not return true already 

Member functions

A member function is a function defined inside a class:

class Sample() { 
  fun foo() { print("foo") } 

Member functions are called with a dot:

Sample().foo() // creates a new object of Sample and calls foo() on it

See Classes and Inheritance.

Generic functions

Functions may have generic parameters which can be specified in angle brackets after the function name and before the value parameters:

fun singletonArray<T>(item : T) : Array<T> { 
  return Array<T>(1, {item}) 

More on generic functions can be found on the page dedicated to generics.


The last argument of a function may be marked with vararg annotation:

fun asList<T>(
 ts : T) : List<T> { 
  val result = ArrayList<T>() 
  for (t in ts) // ts is an Array 
  return result 

By default, vararg creates an array, but this behavior can be customized by providing arguments to the annotation:

fun asList<T>(
<ArrayList<T>> ts : T) : List<T> = ts // ts is a List now!

The type argument to the vararg annotation denotes a builder type. A call to this function is compiled like this:

asList(0, 1, 2) 
// Compiles to 
val list = ArrayList<Int>(3) // 3 is the size of the structure 
asList(list.build()) // For ArrayList, build() just returns the list itself

So, the vararg builder must be a type that has

  • A constructor that takes one Int parameter
  • An add() function
  • A build() function
    The type of the vararg parameter if the returned type of build().

Default arguments

Function parameters may have default values, which are used when a corresponding argument is omitted. This allows to reduce the number of overloads, compared to Java:

// In java.io.InputStream this function has two versions: 
fun read(b : Array<Byte>, off : Int = 0, len : Int = -1) { 
  val actualLength = if (len == -1) b.length else len 
  // ... 

This function may be called in three forms:

read(b, off, len) 
read(b, off) // len = -1, effectively, b.length 
read(b) // off = 0, len = -1

Named arguments

When a function has many parameters (and many of them have defaults), it is very convenient to see parameter names at the call site. Consider the following function in:

fun reformat( 
  str : String, 
  normalizeCase : Boolean = true, 
  uppercaseFirstLetter : Boolean = true, 
  divideByCamelHumps : Boolean = false, 
  wordSeparator : Character = ' ' 
) { 
  // ... 

The best-case call site is fine:


But what if we want to change the word separator without changing the flags?

reformat(str, true, true, false, '_')

Without named arguments, a call site is hard to read. To document it, we can provide parameter names for each argument:

    normalizeCase = true, 
    uppercaseFirstLetter = true, 
    divideByCamelHumps = false, 
    wordSeparator = '_' 

It is better already, but we can improve it: there's no need to specify all the arguments if some of the default values are fine for us:

reformat(str, wordSeparator = '_')

Infix calls

If a member function (or an extension function) takes one parameter, it may be called in infix form, i.e. without a dot after receiver and parentheses around the arguments:

1 shl 2 
// is the same as 

An infix call must have two parameters. One is not allowed to say, e.g. print 1, because there's nothing on the left of print.

Infix calls associate to the left, i.e. 1 foo 2 bar 3 means (1 foo 2) bar 3.

For precedence, see the grammar.

Extension functions

Extension functions allow us to define a function having some type as a receiver:

fun Int.abs() : Int = if (this >= 0) this else -this

This function can be called on any Int with a dot, as if it were a member function:


For more details, see Extension functions.

Higher-order functions

A higher-order function is a function that takes functions as parameters, or returns a function. A good example of such a function is lock() that takes a lock object and a function, acquires the lock, runs the functions and releases the lock:

fun lock<T>(lock : Lock, body : () -> T) : T { 
  try { 
    return body() 
  finally { 

Let's examine the code above: body has a function type: () -> T, so it's supposed to be a function that takes no parameters and returns a value of type T. It is invoked inside the try block, while protected by the lock, and its result is returned by the lock() function.

If we want to call lock(), we can pass a function literal to it as an argument:

val result = lock(lock, { sharedResource.operation() })

Function literals are described in details on this page. Here we only give a superficial description:

  • a function literal is always surrounded by curly braces,
  • its parameters (if any) are declared before -> (parameter types may be omitted),
  • the body goes after ->.
    In our case, there are no parameters, and the expression in the curly braces is the function literal body.

There is a convention in Kotlin that makes our example look nicer:

  • if the last parameter of a function is itself a function, the corresponding function literal may be passed outside the parentheses:
    lock (lock) { 
    This makes our code look more like a 'control structure'.

Another example of a higher order function would be map() (of Map/Reduce):

fun <T, R> List<T>.map(transform : (T) -> R) : List<R> { 
  val result = ArrayList<R>() 
  for (item in this) 
  return result 

This function can be called as follows:

val doubled = ints.map {it -> it * 2}

One other convention helps us here:

  • if a function literal has only one parameter, its declaration may be omitted (along with the ->) and its name will be it:
    ints map {it * 2} // Infix call + Implicit 'it'

These conventions allow us to write LINQ-like expressions:

strings filter {it.length == 5} sortBy {it} map {it.toUpperCase()}

Non-local returns are not implemented yet


See the corresponding issue.

Extension function literals

Like named extension functions, function literals may declare receiver parameters. This allows us to write things like Groovy-style builders in a type-safe way.

Learn more here and here.

Inline functions

Using higher-order functions imposes certain runtime penalties: each function is an object, and it captures a closure, i.e. those variables that are accessed in the body of the function. Memory allocations (both for function objects and classes) and virtual calls introduce runtime overhead. Plus, classes generated for lambdas bloat the bytecode on disk and PermGen at runtime.

But it appears that in many cases this kind of overhead can be eliminated by inlining the function literals. The functions shown above are good examples of this situation. I.e., the lock() function could be easily inlined at call-sites. Consider the following case:

lock(l) {foo()}

Instead of creating a function object for the parameter and generating a call, the compiler could emit the following code:

try { 
finally { 

Isn't it what we wanted from the very beginning?

To make the compiler do this, one needs to annotate the lock() function with the inline annotation:

inline fun lock<T>(lock : Lock, body : () -> T) : T { 
  // ... 

Inlining may cause the generated code to grow, but if we do it in a reasonable way (do not inline big functions) it will pay off in performance, especially at "megamorphic" call-sites inside loops.

General guidelines for what functions should be marked inline:

  • Do not inline big functions.
  • The primary purpose of inline function is to inline lambdas at call sites. It is rarely a good idea to inline a function that does not take other functions as arguments.

Some functions can not be inlined. For example, if you do not call a lambda argument, but use it as a value (e.g. put it into a map).
The compiler will refuse to accept inline annotation on such functions.

By default, all functional parameters are inlined at the call site, if you want some of them to be passed as values instead, annotate these parameters with noinline:

inline fun twofun(a: () -> Int, noinline b: () -> Int) { 
    a() // only call: fine for inlined parameter 
    mylist.add(b) // add to collection, fine only for noinline parameter 

Inline functions are in *experimental* state


To disable inlining, use the "-inline off" command line key.

See the corresponding issue.

What's next

  • No labels


  1. The LINQ-like example with infix calls looks really nice. How hard is it to write map and filter if you want lazy evaluation instead of eager? Is there anything like C#'s iterators or Python's generators? Or would you just need to write your own Iterable<T> subclass?

    1. We are considering support for C#-like yield

      1. I would love to see "yield".  For generators and other lazy sequences, it is magical.

  2. Anonymous

    A very interesting approach to a new language, i like most of your ideas, really.

    Having tuples, multiple inheritance and the property syntax are some of the things i really missed in my java experience.

    But there's one thing i don't like and that's the abbreviation of the "function" keyword as "fun"!

    There are two reasons, why i don't like it, one is the meaning of the "word", but the other is more important to me.

    I don't know why it is the way like it is, but somehow most of the keywords used in expressions and such are relatively short while the keywords denoting major constructs like "namespace", "class", "module" and also "return" are relatively long.

    So maybe it's something about code readability.

    I vote for using "function" as the keyword for denoting functions!

    1. Anonymous

      I agree that "fun" is difficult to visualy parse. I'd rather see "func".

    2. I agree with this comment. The keyword "fun" to denote a function just doesn't seem right. I am okay with "function". I believe command-line completion would take care of having to type out the whole word. If you want to have an abbreviation, I would prefer "fn" or maybe "func".

  3. Anonymous

    How does function/method overloading work in the presence of function types? E.g., is it possible to declare:

    And also overload it with:

    1. No, this is not possible in Kotlin. Partly because the Java platform constrains us, partly due to difficulties in type inference, and mostly due to being a discouraged practice. You can have overloads that differ in function arity, though, for this is very visible at the call site

  4. Anonymous

    The syntax for named function arguments seems risky/confusing to me. There is potential confusion between an identically named local variable at the call site and a function parameter used as a named function parameter. For instance, if I see code like this:

    val foo = bar(baz=qux);

    I can't tell if this is a local variable named "baz" being assigned to qux before being passed into foo, or whether it is a named function parameter named "baz" being passed the value qux.

    I would like to see some sort of different syntax used to refer to function parameter names, so that it is clear when reading a code whether the name refers to a function parameter name or not. Perhaps a leading "@" or "#" or some other character on the function parameter name? Or using ":=" or "::=" instead of "=" as the separator between the variable and its value? Making these syntactically distinct could also speed up compilation, since the compiler would know ahead of time whether to search for the named variable in the calling scope or in the function declaration scope.

    1. Note that assignment cannot be used as an expression in Kotlin, so foo(bar = 1) is always a call with a named argument, and never an assignment.

  5. Anonymous

    The name "Unit" seems very nonintuitive to me for what this class does. I would expect a class with a name like Unit to be associated with things like meters, inches, kilograms, and furlongs per fortnight, not for it to be the class associated with methods that don't return any values. I'd like to see this class renamed to something that more clearly expressed its purpose in the language. Something like Empty or Void, perhaps. (It seems to serve in some ways a similar purpose to java.lang.Void, as far as I can tell, so that might be a good choice.)

    1. The type Unit is not empty (empty type is Nothing). It's a singleton type, i.e. has only one value in it.

      1. Anonymous

        So then it really IS like java.lang.Void, which has exactly one value -- the null pointer.

        1. (smile) Null is somewhat special. And the value of Unit is not null.

  6. Anonymous

    0. How easy it is to pass member function to some another function?

    1. Did you consider adding support for partial applications?

    2. Infix notation is nice; did you also consider adding $-notation (like in Haskell)? It allows to get rid of many parentheses.

    1. 0. foo {a.bar()}
      1. Not as a language feature, but you can do this: {{ {1 + it} }}
      2. I don't see a way of making this efficient

      1. Anonymous

        oh i see. so no point-free then.

  7. Anonymous

    Your example for named arguments is another good illustration that boolean values in function call make the code unreadable. Instead of named arguments I would consider redefining true/false for booleans in function definition. For example:


    in function call could be used as:


    I added # to distinguish normalizeCase parameter name from a local variable possibly having the same name. Exclamation stands for boolean NOT. That syntax is much shorter from caller's point of view. It's the same as if I would define a local variable called #normalizeCase with the value of true.

    I also join the opinion that "fun" abbreviation looks ridiculous. I would vote for "function" too.

    1. I have had this reflection too at some point about boolean parameters inside languages in general.


      is better than

      1. Anonymous

        One of the pieces of advice from the book "Writing Solid Code" that has stuck with me over the years is that in many (most?) cases, it is better to use two-element enumerations than it is to use booleans. Some reasons include:

        1) The enumerator names are self-documenting. It is clear that "enum PaintColor {RED, GREEN}" that the constant RED refers to the color red. It is less clear in the function call "doPaint(true)" that the parameter 'true' is being passed to indicate that the painting should be done in red.

        2) You can do an IDE search on "RED" to find all places it is referenced. It is hard to do a search on "true".

        3) You can do an IDE search on "PaintColor" to find all places that the type is referenced. It is hard to do a search on "boolean".

        4) You can add additional methods to the enum if you need to (e.g. "toString()" or "getRGB()" that would otherwise be scattered auxiliary functions if you were passing booleans around instead.

        5) If you decide that a third option is needed, you don't necessary have to rewrite all of your code to use a different type or pass a second boolean flag.

        6) The enums provide extra type safety and hence mistake prevention. You remove the possiblity that you might accidentally swap two booleans being passed into a method call, which the compiler couldn't detect.

        In Java, using enums this way is a little bit annoying since by using one, you always introduce a third possibility of passing 'null' that unctions receiving an enum parameter must be wary of. It seems that Kotlin will not have this problem.

        1. Anonymous

          I'm not sure how that "Unknown macro: " phrase with its associated line breaks got into the above text. Please ignore it. Apparently the wiki is somehow trying to interpret text inside curly braces as commands.

          1. You can escape "}" with a backslash

    2. Anonymous

      Fun Pros:
      -Has three letters just like "val" and "var".
      -Quicker to type
      -Takes less real estate on a line

      Fun Cons:
      -It collides with a cute and un-enterprisy dictionary word.
      -"function" is too much of a sacred and sexy word to be abbreviated.

      1. I think "func" looks more like an abbreviation from "function". At the same time it has the same pros, just one extra character doesn't make a big sense.

        1. It might seem trivial, but I don't like "fun", either. When I read it, I don't think "function" right away and it just seems kinda silly (funny? :-). I don't think "function" needs to be abbreviated at all. The abbreviated version doesn't really add any value, so why not just use "function" as the keyword?

          That being said, if an abbreviated form must be used, then I would prefer "func", because it at least makes me think "function".

          On var/val: Again, no real value from shortening them, but they're consistent with Scala (and other languages, I'm sure), and they make me think "variable" and "value", so I have no issue with them.

  8. One question related functions.

    Lets imaging the library function requres a function with one argument, like the following one:

        fun List<T>.sortBy(f: fun(x:T))

    And for my class, I've got a function with two arguments:

        getName (x: MyClass, inLowerCase: Boolean = false): String

    So does Kotlin accept something like the following

        myObjects.sortBy(MyClass.getName(inLowerCase = true))


    1. No. Currying is not supported in this form. What you can do is:

      myObjects.sortBy {MyClass.getName(it, true)}

      or better make use of extension functions:

      fun MyClass.getName (inLowerCase: Boolean = false): String 
      myObjects.sortBy {it.getName(inLowerCase = true)}
  9. Anonymous

    What is the scope of "it"? How nested "it" are managed?

    1. The scope of it is the function literal it is defined for. Since it is a normal variable (just implicitly declared), so when a nested scope defines another it, it will shadow the declaration of the outer scope.

      1. Anonymous

        So having

        we couldn't say to which braces "it" corresponds to, right?

        1. If we are the person reading this code, then the answer is no, if we don't know what parameters b and d expect. Of course, IDE tells us if we ask.

          1. Anonymous

  10. Anonymous

    Does Kotlin support dispatching based on the runtime type of its arguments?

    1. No, since there's no efficient way to implement it + multiple-dispatch complicates class hierarchy semantics.
      See discussion in this paper: http://www.cs.cmu.edu/~donna/public/oopsla09.pdf

  11. The infix call syntax makes me nervous and is the thing I like least about Kotlin.  It's also one of my least favourite features of Scala.  It has the potential to make code look very inconsistent and therefore be much less readable.

    When would developers be expected to use the infix form instead of a normal call?  Always?  Under certain special circumstances?  When they feel like it?  I also don't like the way it makes calls with a single argument look completely different from all other function calls.  They aren't fundamentally different, they only differ by the number of arguments.

    I think the flexibility for writing DSLs and the nice examples it enables are too high a price to pay for the inconsitency it introduces.

    1. A few questions:

      • Do you think the same about operators (+, * etc)?
      • Do you think we could make it better by only allowing specially annotated function to be called in this way?
      • One of the main use cases for infix calls is for rarely used and custom operations with inherently infix nature such as bitwise or/and/xor, shifts of all sorts, implies() logical operation and such. Maybe you have an idea how to keep these around without introducing new cumbersome symbols on the one hand, and infix calls on the other?

      Thanks for your replies.

        • No, I have no problem with infix operators. They are what everyone is used to from maths and most other programming languages. The infix form is always used for operators so they are consistent.
        • I think it would be a lot better if the function definition specified that it should be called using the infix syntax. Particularly if those functions could only be called using the infix syntax. I hope that forcing developers to declare that a function uses the infix syntax would make them think more carefully about whether it is appropriate. If the decision is left to the caller of a function then the calling style can change on a whim and it can change from one invocation to the next. I know this from experience - my own Scala code went from one style to the other several times and I could never decide which I preferred. The result was a bit of a mess.
        • I think a reasonable compromise would be to allow functions to be defined as infix functions and not allow them to be used in any other way. That could be a very useful feature.

        One of the main things that put me off Scala in the end was the flexibility of the syntax. Developers can't resist pushing things as far as they can and some of the results are very difficult to read and understand. Kotlin has already avoided one of Scala's biggest problems by not allowing arbitrary operators. I think the arbitrary use of infix function calls is another thing Kotlin would be better without.

        I don't think the example looks too bad using normal function calls:

        Doesn't look significantly different from:

        One of the key things about LINQ is that the infix syntax can only be used inside LINQ expressions. Method calls everywhere else in C# use the dot syntax. LINQ expressions are a separate world where different syntax rules apply.

        1. You are making a fair point.

          One problem with what you propose would be the inability to call a infix function on a nullable receiver (no ?. operator). Currently you can't call an infix '+' on a nullable Int, but have to fall back to the longer form a?.plus(b), this would be impossible for infix-only functions.

          1. I hadn't thought of that.  How about this: functions declared as infix can be called using either syntax.  Functions that aren't declared as infix can only be called using the conventional syntax.

            I think the biggest problem would be people choosing the infix syntax for calling normal functions.  If a function is declared as an infix function I think people would probably choose the infix syntax anyway.  And even if they didn't it would be OK, you'd get code like this which is easy enough to understand:

            instead of

            1. This looks like a good idea. Actually, we have exactly this discussed yesterday, but it's not on the issue tracker yet. I'll file an issue. Thank you.

  12. My two cents on "inline"...

    I don't really like the idea of an "inline" keyword. I'm not against inline functions, but I think that it should be completely up to the compiler to decide which functions would benefit from being inlined.

    Some likely scenarios:

    1. Let's say you have a small method that is only called a few times that is a good candidate for inlining. However, as the method grows or becomes called from 10 places instead of 1-2, the developer will have to remember to remove the inline keyword at some point. Why should a developer have to worry about something like that? Ideally, they should only worry about writing working code, not about optimization.
    2. If you have a large method that's only called in one place (especially if it's a loop), it probably makes sense to inline it. However, if it's called from a second or third place, all of a sudden inlining doesn't seem like such a good idea. If you forget to remove "inline", you could end up with quite a bit of bloat. On the other hand, when you remove "inline" you will lose the optimization of inling the method in the original loop. In this case it might be desirable to inline the method in one place, but not in the other places.
    3. If you have a small method that seems like it should be inlined, it's likely that the developer won't even remember to add "inline" and may even choose not to add it because they don't know how the method might be used in the future. If there are performance problems they might go back afterwards and add it in, but really, the compiler should have been able to determine that optimization on it's own.

    I think that if it was solely up to the compiler (with optional optimization settings/flags from the user) to inline functions, the resulting bytecode would generally be much more efficient and would save the programmer from having to worry about such things.

    1. The compiler your use cases are up to is JIT, not Kotlin compiler.

      You need inline only when it prevents closure allocation or in very similar situations. Such functions do not tend to grow.

      Plus, the compiler can warn you in the rare case of inlining a huge function many times.

  13. Will the following work:

    fun main(args : Array<String>) { 
    val result = testMultipleReturn("test1", "test2"); 
     System.out?.println(result.value1);  // INSTEAD OF ._1 
     System.out?.println(result.value2); // INSTEAD OF ._2 
    fun testMultipleReturn(inValue1 : String, inValue2 : String) : #(value1 : String, value2 : String) { 
    return #(inValue1, inValue2) ; 

    I would be nice to have this feature.  

    1. Yes, it will, once implemented. See Tuples.

  14. The LINQ style example "stringsfilter {it.length==5} sortby {it} map {it.toUpperCase()}" looks very interesting from a DSL builder's point of view.

    Does/will Kotlin provide a way to read the AST of a code fragment - like Java Reflection/Class API but with an actual AST of the method, closures and expressions?

    1 usecase would be allowing the user to write type-safe queries/expressions in pure Kotlin, but at run time the expression will be "parsed" and transformed into a database query or a memcached/redis query.

    1. Yes, we are planning to support this.

  15. Example of "Extension Function" has a couple of errors. First, function returns Int not Boolean..

    And caller needs parentheses around a negative number because unary-minus binds less strongly than invocation.

  16. Will it be possible to pass a named function directly as an argument to another function?

    It could be even better if compiler could accept TArg.() -> TResult where (TArg) -> TResult is expected :

  17. in the example that given for generic functions:

    I keep facing ClassCastException when I'm trying to use it.

    I've tried following approaches: 

    but the result is this exception:

      1. And this is happening only in Array. If I change the function to: 

        It will compile and run successfully.

        btw, is this bug logged in youtrack yet?

  18. This is kind of confusing: 

  19. few minor issues in the page:

    - in varargs example

    - in Higher-order functions

    -  Do we still need 'tuples' section?  

  20. Is there any way to pass a pointer to a an object's function as a function-type argument?

    e.g. I have some traverse function, that processes some pairs. Also I have a parametrized processor class that can process such pairs.

    Now I'd like to write

    instead of

    1. Not supported yet, but will be. See this blog post, under "First steps in callable references"

  21. Could Kotlin support fluent style by default, such that any method that returns Unit implicitly returns "this", allowing method chaining.  for example

    1. This would affect other aspects of the language in an undesirable way.

      1. I like the way Kotlin eliminates much of the boilerplate code, simplifying fluent style member functions would be helpful, especially in the case of subclassing or delegation.  

        For example

        I can override each method just change its return type, but this laborious. Maybe generics can help?

        This does work but is a bit tricky, it would be great if Kotlin made this better, more direct.
        A class modifying annotation like 'data' could be added, called 'fluent'. Class or member functions annotated with 'fluent' would implicitly return this, unless method explicitly returned a value.  This option also allows for compact, single line methods, which I love in Kotlin.  

        Another option is return a special type 'this' which would indicate this's type, that of this class or its sub-class. I believe this is the most flexible and obvious syntax;

        1. The generic version falls short of generality: doesn't play well with inheritance. That's why the "this" type version is very tricky to fit into the language design and is likely to complicate it significantly.

          The annotation version may be an option indeed.

  22. It may be useful for tiny fuctions to use unnamed parmeters. I mean

    also this wil shorten some literals


    1. This doesn't seem to be beneficial: we read a lot more code than we write, and having nameless parameters obscures their meaning

  23. Just wondering: since Kotlin is compatible with Java6, does this mean that functions are somehow wrapped in a kind of one-function objects (in Kotlin)? I'm mainly wondering because untill yesterday I thought Kotlin made use of the amazing invokedynamic-instruction for the fun stuff like functions and lambda-like expressions. However, this can't be true, due to compability with Java6.

    1. We are not using invokedynamic for now, and I'm sad dissappoint you: using invokedynamic saves only some "one-function objects", by far not all of them.

      1. Hey Andrey, not such a big dissapointment, more like: how did you implement the function type? Can I compare it to some kind of "one-function objects'? Well, it's maybe up to me to find out :).

        1. We are doing it pretty much like Scala (and Java 8's approach is similar): there are predefined interfaces Function0 .. Function22 and lambdas are compiled to their intantiations

          1. I don't know about Scala, however, I (think I) do know about java8, and it looks somewhat different (but again, I'm not sure if I got it right). In Java8, lambda's are not some kind of function type (which seems to be Kotlin's and Scala's approach, if I understand well?), nor is it syntactic sugar for inner classes. In Java8, lambda's are extracted as a static function.

            That's where, in Java8, 'invokedynamic' and stuff comes in... (As far as I understood, they actually exposed invokedynamic to make lambda's work, with the benefit that that instruction is available from Java as well). That's why I was somewhat confused (not dissapointed :) ) about Kotlin. I might try to make some kind of small comparison between the different implementations (inner classes vs Kotlin's approach vs Java8's approach). Just for fun ;).

            Thanks a lot!

            1. You are right that static methods play a big role there, and invokedynamic makes it possible to rely on static methods. But in fact, Java 8 creates instances of SAM-interfaces that lambdas are converted to nevertheless. Only these instances are more like proxy objects and their classes are created through runtime byte code spinning.

              1. The little bastards... So far, I never understood properly how exactly they managed to get it all done. It starts to make much more sense now :).

              2. Just some thoughts that came up:

                1. So for all the dynamic languages that run on the JVM, Function-objects are generated... Never thought of that, although every Function-object is (only) created once.
                2. Maybe more interesting: with the invokedynamic-approach, a kind of Function-object is only created once (being on the first call and through some 'runtime byte code spinning' - I like the way you describe it). How's that in Kotlin? Are new Function objects created every time a function is called, or is there some kind of genius optimization with respect to Function object creation?
                3. I tried to find out about how Kotlin was implemented and started to check on the Function interfaces. It was kind a funny - no offense intended! - to see that there are a bunch of Function-types, up to 23, as you mentioned in a previous post. I wanted to see why exactly 23... Any reason to choose 23 Function types (being a function with 1 output and 22 inputs)? I'm just curious why not choosing 42 :). - Well, I just can't think of a Function that needs more than, well, let's say 3 inputs.
                1. 2. For now we create an instance on every call. This will be optimized at some point. + We are working on inline functions that do not create any instances at all.

                  3. This is a mystery. Martin Odersky would be the next in the chain to ask, because we copied this number from Scala (smile)

                  1. Inlining would be pretty cool, indeed. And having 42 Function-interfaces would make Kotlin way cooler than Scala ;).

  24. This comment is on another page, and it seems that it should be on this page as well:

    "Non-local returns are not implemented yet

    See the corresponding issue."