Naming issues... Where are all those programming languages where uuids are identifying things in code and names are optional, but recommended for readability? 😉

I like the new

also

. It would be nice if there were something similar for

with

so that nested

with

statements could use named receivers instead of

this

Just write point-free 🙂

@nstewart what about https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/let.html? ^^

@nstewart

with

with named receiver is just

let

😳 thanks @Andreas Sinz @ilya.gorbunov! I had not thought of using

let

in that way. All examples I’ve seen of it are used to better deal with nullable arguments

We're not planning to take more features in the standard library in 1.1, so technically it already happened )

We'd like to distinguish them from existing `min()`/`max()` extensions available for collections.

And also it sounds more natural when you read it, like 'minimum of two values'

val value: Int = map.getValue("key")

Have you considered

getValueOrThrows()

? Would make the intent a bit more obvious IMO (arguably carried by the non-nullable return type, but still useful in a language with no checked exceptions)

.takeIf { ... }

makes me think it might be useful to have a

.orElse { ... }

or similar that is basically a function version of the Elvis operator. Would be useful if you're chaining more methods afterwards because with an Elvis, you'd have to wrap the expression from the very start up to after the Elvis in parens, which can get kind of messy Kind of a contrived example, but:

val lastTransactionId = api.getUser("userId")
    .takeIf { it.transactions.isNotEmpty() }
    .orElse { error("user has no transactions") }
    .transactions.last.id

vs

val lastTransactionId = (api.getUser("userId")
    .takeIf { it.transactions.isNotEmpty() }
    ?: error("user has no transactions"))
    .transactions.last.id

Thoughts?

I guess it'd just be

inline fun <T> T?.orElse(ifNullBlock: () -> T): T = this ?: ifNullBlock()

@kevinmost Will a

return

work in the

orElse{}

block? That’s one of the main appeals of the

?:

current approach

@cedric I think it would since

orElse

is inline, right?

You won't get smart casting, though

@damian where does smart-casting come into play when using Elvis? Not saying it doesn't, just curious

if you have

val x = y ?: return

,

x

is either y's type (non-null) or

Nothing

so if

y

is of type

T?

, then

x

is inferred to be of type

T

, right?

right

but I was wrong

you still get smart casting

the same applies with this implementation of the orElse function

not sure why I didn't think so

🙂

@roman.belov Sorry for the late feedback! I find at least some of the latest additions to be unnecessary. Extensions to

Any

(like

also

) pollute the namespace of any object with new symbols, so those that mostly cover corner cases rather than universally useful concepts should have really really good reasons to be added. I looked at https://youtrack.jetbrains.com/issue/KT-6903 and I'm wondering on which basis the decision was actually made to introduce

also

? I mostly find discussion around naming rather than a proper rationale for why we need to have all these subtle flavors of

let

in the standard library. I think additions with such reach should be considered "guilty by default" and only made if there is a vast majority of cases proving they're needed. Maybe I'm missing context to the discussion, just wanted to offer another point of view to this.

Maybe one more point: I really liked that Kotlin decided to only define equals, hashCode and toString on

Any

, whereas

Object

defines methods related to threading on top of that, something which I understand has been pointed out as a mistake not to be repeated. Isn't defining extensions on Any going doing the same path?

@ilya.gorbunov

window

not making it in 1.1 is a shame

Current proposal isn't satisfactory, and needs some rework, which we hadn't time for. I hope we'll provide it in the first milestone of 1.2. That way we'll have enough time to eap it, which is really needed for such proposal, given the amount of questions it has.

I see