it's probably the most needed function in advent of code 😄

@kevinmost Interesting suggestion about

orElse

, though I'm rather skeptical about whether we should add a function which provides slightly different syntax to the language operator. Please, create a feature request, so we could consider cons and pros there.

@ilya.gorbunov will do. On YouTrack, right?

@mk i'm also not a huge fan of adding more extensions to Any (

to

, sigh), but the reason people object to threading things on Object is partly because the API isn't very good and partly because it imposes runtime costs that are hard to optimise away (though hotspot does a pretty great job of it)

right, I see.

Any

extensions are free at runtime. So that leaves the "not good api" part. Well, other than perhaps being a bit superfluous, functions like let, apply, also etc are too simple to be called APIs. so i think it is not a big deal.

the real cost there is just remembering what they do and picking between them.

i think the assumption is that you pick whichever word would work best in an english sentence.

I think the main thing that put me off was that I had recently been trying to define

run

on

Future

, but realized that this extension would shadow a stdlib method, which I considered a no-go. Adding more methods that are available on Any out of the box takes away room for apps and libraries to extend library types. Maybe it's not a big deal after all, but it is something I noticed.

I just posted this question at the bottom of the 1.1 blog post: What is the reasoning behind creating

onEach()

? What does this give a developer that you can’t get from

forEach()

? I don’t think it is clear to a new developer to the language that calling

onEach()

returns the iterable instance for the next statement in the chain. In the example above I would just call

forEach()

in the following way:

.forEach { f ->
  println(“Moving $f to $outputDir”)
  moveFile(f, File(outputDir, f.toRelativeString(inputDir)))
}

functions like let, apply, also etc are too simple to be called APIs. so i think it is not a big deal.

Maybe not. I guess my general stance is, if they're so simple, people should define them themselves, especially when they can be derived from existing methods

And to take a page out of the Scala book, aren't they regretting to have added so much alleged utility to the language library early on? Now they're stuck with a fat runtime library.

The beautiful thing about Kotlin is that it is so easy to extend with extension functions, they don’t need to be baked into the standard lib

Exactly--but I think extensions should be left for client code, not the platform.

I personally don't think it's that big of a deal to be adding basic operations like this to

Any

. I know that if they weren't in

Standard.kt

, I'd be defining

let

,

apply

, and

also

at the very least in all of my Kotlin projects. That's what a stdlib is for, arguably

@ilya.gorbunov https://youtrack.jetbrains.com/issue/KT-15962

@kevinmost I can see the benefit of that

looks much cleaner

although, I don’t understand what

ifNullBlock()

is

agreed, and it also lets you work in a much more fluent manner. If you realize that you need to chain something to the result of an expression that uses an Elvis, you have to go back and put a paren at the start of the expression which really breaks the flow IMO

it's the default value

it's the lambda that gets executed if

this

is null

maybe a better name is in order

yeah, basically the function that produces the default value (so that it can be lazy)

yeah, I get that but in the example I can’t see where you pass the default value in

keep in mind though that this will be defined on any object, even on non-null types

since

T?

will include

T

@arthur in this example, my "default value" is to throw an exception, which returns

Nothing

, which is a subtype of

T

, but you could also do

.orElse { defaultUser }

, for example

it would be nice if there was a way to express that an extension should not affect non-null types

@mk yes, you're right, this is definitely an advantage of the Elvis operator. The compiler will tell you if you use an Elvis on a non-null type that you should remove it