A modern programming language that makes developers happier.

kotlinlang

is `return@` considered harmful or unidiomatic?
for example, I want to make a function that sums up the number of values of a list, or returns `null` if a certain value is detected. I wrote it as
```fun List&lt;Foo&gt;.calcSum() = this.fold(0) { sum, val -&gt; if (something) { sum + val } else { return@calcSum null } }```
is this bad style?
I had to add a type hint for the function to even compile.

That does not even compile, so I'd say it is bad style :smile:

But even if I replace the invalid `val` by `value` and replace the undefined types to have
```fun List&lt;Int&gt;.calcSum() = this.fold(0) { sum, value -&gt; if (kotlin.random.Random.nextBoolean()) { sum + value } else { return@calcSum null } }```
I get
&gt; Type mismatch: inferred type is Int but Nothing? was expected

Besides that I think that the `@calcSum` is redundant here as a simple `return` would have the same effect.

Ah, with an explicit return type it works
```fun List&lt;Int&gt;.calcSum(): Int? = this.fold(0) { sum, value -&gt; if (kotlin.random.Random.nextBoolean()) { sum + value } else { return null } }```
while I personally would use an extension property
```val List&lt;Int&gt;.sum: Int? get() = this.fold(0) { sum, value -&gt; if (kotlin.random.Random.nextBoolean()) { sum + value } else { return null } }```

But that of course says nothing about idiomaticness :confused:

It has its place but in most cases its preferred to use the implied return we get from the last line of the lambda expression

<@U0152P3VB5J> yep, the explicit return type is what I meant by adding a type hint. heh.
an alternative to this syntax is a fold that returns a sentinel value, maybe `-1`, followed by a `.takeIf { it &gt;= 0 }`

But that would still iterate the whole list instead of short-circuiting.

oh yeah, I forgot to mention it would still require `return@`, except it would return from the `fold` rather than the function.
all in all, not an improvement. this is a problem that requires either two passes (one pass to verify input, second pass to sum) or one pass with short-circuiting. I do think `return@` is the right solution here.

```fun List&lt;Foo&gt;.calcSum() = 
if (!something) null
else this.fold(0) { sum, val -&gt; sum + val }```
can’t something like this work? or is `something` depending on `val/sum`? (I find it more readable, don’t know about idiomatic)

<@U0QAY96MA> the issue here is that the `something` is a property of one of the values so it is discovered on-the-fly.
for example if `Foo`  is a `sealed class` with one “number” variant and one “not a number” variant, and you want to sum a `List&lt;Foo&gt;` such that a sum is `null` if any of the values is not a number.

I guess I can also write my own `fold` function with a closure that allows short-circuiting.

I thought that a return in a lambda expression by default goes to the outer function. You only need a label if you're trying to return a value for the fold to pick up.

oh, that seems right to me - good point. I’m used to another language where this is not the case.
edit: it does work like that.

`return@` has its usages, mostly for returning from lambdas to enclosing functions
<https://kotlinlang.org/docs/returns.html#return-to-labels>