btw, why do the “index of” collection methods return

-1

on absence rather than

null

?

Because in java it would return Integer which is object allocation

performance ? or is it because it simply maps the Java APIs to mutable / immutable interfaces for now ?

Performance is probably why java done it.

But it also like that in C#,js and I guess more languages

indexOf in java returns a primitive int

so you can’t return null

right, kotlin collections are interoperable with java ones.

I find it is way handier to use when returning

null

though, is it just me ?

you could create your own extension function that return nulls

Create

indexOfOrNull

, it's free and encouraged to make things the way you want. There are a lot of posts where people want different things. Which is great, readability and coding styles vary. Kotlin is designed so you can extend API as you need. If things happen a lot in the wild, analysis of public code tells the team what changes to make (maybe) in stdlib. So to get changes to stdlib, it's not about talking here; it's about doing it, many people doing it, and pull requests or youtrack tickets.

Null for indexOf() is actually a good idea, thanks to Kotlin's type system. Other languages would use exceptions. In assembler we might just set a flag. And in imperative languages it must be some negative value in a signed integer.

@dgreenhalgh has left the channel

@hastebrot: Agreed, I would prefer

l.indexOfOrNull("foo").let { // do something }

over testing against

-1

Maybe

indexOf { }

you could create a temporary object (singleton) from the first function that has

else { ... }

on it

Or maybe it can return boolean and have extenstion method:

Boolean.else(func: () -> Unit) { if (!this) func() }

can you create an extension with a reserved word as name?

But your extension function would show up only if imported and will bleed I to other uses of boolean. You can just make a singleton for all uses of

otherwise

and therefore only one global allocation.

I there any std class for

Future

just like scala?

@jasoet-gdp: No, there is no one yet.

How about

Try<T>

on kotlin? is it possible to write composeable code just like Scala (again)?

@jasoet-gdp: Probably possible, you can get away with this without support for highed kinded types

Personally, I've never been convinced that collecting errors this way leads to more readable code than using exceptions. I prefer to lose referential transparency and gain readability (and avoiding boiler plate, which

Try

and similar encourage)

@cedric: i don’t really like try-catch everywhere, with

Try<T>

every method that returns value enclosing with

Try

i know that i need to handle that.

with

Option<T>

and

Try<T>

i can use map, flatMap to compose the code

You shouldn't have try/catch everywhere, just

throws

wherever you have to