why is this valid

maybeNull() ?: return

but this isn't

maybeNull() ?: { return }

In the second example the right-hand side of the elvis is a lambda expression (

{ ... }

sometimes delimit lambdas in Kotlin, not always code blocks). And this lambda doesn't allow non-local returns

odd. it has no captures or args, why would the compiler think it's a lambda?

A more complex example:

fun main() {
    val x = maybeNull() ?: run {
        println("In the null branch!")
        return
    }
    println("Got some non-null x: $x")
}

private fun maybeNull(): String? = null

https://pl.kotl.in/pGwEnQHEj

codeblocks are simpler and less less overhead than lambda or captures. I'd assume it would always try to generate the simplest code, until it finds out it can't.

Code blocks are completely different from lambdas, so there is no real point in comparing complexity here. The behaviour is just not the same at all. Code blocks execute immediately while lambdas are function literals that represent a value of a function type, can be passed to other functions, assigned to variables, and later executed. It's not a matter of compiler optimization, it's a language design decision to interpret which syntax in which way. Some syntax constructs allow code blocks, like

if

,

when

,

init

, function bodies, etc. If you're not using such a syntax, Kotlin consistently interprets braces as lambdas AFAICT, so it's not too surprising once you forget about arbitrary code blocks in the middle of some code flow. There is almost no use for code blocks outside syntax constructs, and every time I saw standalone code blocks in Java, it was either a mistake or a code smell that a piece of code really should have been extracted into a function.

Code blocks are completely different from lambdas, so there is no real point in comparing complexity here

Isn't that exactly when you want to compare complexity? When things are different? code blocks also control scope. So I think saying they are useless outside of syntax is a naive.

Isn't that exactly when you want to compare complexity? When things are different?

If the things you compare don't serve the same purpose, you wouldn't use them interchangeably, so I'm not sure why you would want to compare their complexity. It's like saying a class is more complex than an

if

statement - I don't quite see the point. In the context of our discussion, you mentioned I'd assume it would always try to generate the simplest code, until it finds out it can't. I don't understand how you would even define "simplest code" then here. The simplest code that does what? The simplest code among which options? The fact that you put "code block" or "lambda expression" in the list of options to compare is arbitrary, and the language design team decided there was no ambiguity here - it is just "lambda expression".

using

{ }

for scoping in Kotlin (or Java) isn't super meaningful, as it doesn't let you re-bind variables and it doesn't give you RAII (note that JVM is allowed to garbage collect references even before the end of the block, if the reference will not be used later)

If the things you compare don't serve the same purpose, you wouldn't use them interchangeably

We're talking about an EXACT case where they can be used EXACTLY interchangeably.

{}

always means lambda except when in specific control structures, I don't think it's confusing at all

how is

:?

not a control structure?

?:

takes an expression on both sides,

{}

as an expression can only be a lambda

isn't it just short hand for

if( thing == null)

if you want to think of it as shorthand, then

run { val tmp = maybeNull(); if (tmp != null) { tmp } else { { return } }

is the equivalent of what you wrote

right. which of those are lambdas, and which arn't?

run@{}

is a lambda, and

{ return }

is a lambda

I assume you mean result in a value?

{ return }

is a

() -> Nothing

(or possibly a

(T) -> Nothing

,

T.() -> Nothing

, or

T.(U) -> Nothing

depending on context)

We're talking about an EXACT case where they can be used EXACTLY interchangeably

Not at all. That's exactly why I initially wrote that they are different, because I was expecting that maybe you had misunderstood this part. The lambda would NOT be executed immediately in this case, it would just be a value of a function type. For instance:

val x = null ?: { println("test") }

In this case the value of

x

would be a function that prints

"test"

when invoked (

x

would be of type

() -> Unit

). But running this code would NOT print anything. If that were a regular code block, it would print.

in any case,

{ return }

involves a non-local return, which can only be performed from an inlined lambda, which does not match the context in your example. but that comes up after the grammar has already decided that it is a lambda.

does not match the context in your example. but that comes up after the grammar has already decided

I think that's the exact point I'm trying to make.

the only possible meaning for

{}

as an expression in Kotlin is a lambda, full stop. there are no scope-only blocks.

so your saying

{}

is always a lambda, even in simple if/while statments?

no, because that is not where an expression goes

so even in the case of

val x = if(true) {1} else {2}

that's not an expression?

no.

{1}

is a block, which contains one statement, which contains one expression, which is an integer literal

if you wanted to use lambda expressions as branches in an

if

expression you would need 2 pairs of braces

he only possible meaning for 

{}

 as an expression in Kotlin is a lambda, full stop

so... this isn't true then...

I said and highlighted expression

you did later, when we talking about control blocks... yes. But I think if I hadn't brought those up, you would have let the statment stand.

given the limited number of symbols on our keyboards, yes.

hmmm... I think your being an apologist at this point.

that would lead to other effects throughout the language

Any pair of braces could be a lambda. Not yielding a value is not a thing in Kotlin. There are

Unit

and

Nothing

types. Every block could therefore be a lambda. Thus the content of the block cannot help determine what is or isn't a lambda. However, limiting blocks to control flow syntax, and interpreting lambdas in every expression is really consistent, and honestly not that hard to grasp

you can compare to Scala which chooses a different interpretation of braces

rust uses

||

to denote a lmabda, as well as define params... which I think is much better. never liked that the params are defined inside the lambda in kotlin

{key,value-> stuff}

as apposed to

|key,value| {stuff}

which is far less ambiguous, and the exact same number of keysstrokes.

doesn't let you build DSLs as naturally though, unless you embrace the Ruby-like approach of calling without parentheses, which leads to other complications