but a keyword less, I guess

I just thought through the

assertFailsWith<T>(class: KClass<T> = T)

syntax. For this to be convenient Kotlin will have to change its rules for default parameters. By the java convention

class

parameter should go first. But in kotlin all parameters after a default one must be named. So the usage would be

assertFailsWith<MyClass>(message="one word too long")

.

Frankly speaking, I have no idea how to walk around it

hey guys, question regarding stdlib -- I was researching about Kotlin's functional programming capabilities, and saw that there are methods such as

filterIndexed

,

forEachIndexed

and

mapIndexed

, as well as a few variants of each of those. However, there's no indexed counterpart of

reduce

. Could anyone shed some light on the reason?

@gabrielborges : probably no reason, you are welcome to fill an issue / contribute

@ilya.gorbunov : https://youtrack.jetbrains.com/issueMobile/KT-7930 It 's about nullable string parsing

String.toInt(): Int?

Is your opinion on the topic the same?

Also I wanted to hear from the broad community

@voddan: cool, will try and put together a PR at some point

@gabrielborges which option?

toInt

or

toIntOrNull

?

toInt.

Glad to hear that. Currently this issue is a hole in API

What do you mean by “hole”?

By that i mean that every programmer should remember to catch exemptions on parsing the input by himself

It really depends on type of code. E.g. if I’m doing some throw-away command line program, I don’t want to care about nulls and exception, just let it die with a stacktrace. In other cases, e.g. in protocols, incorrect number in a stream is an “exceptional” situation and better be handled as such. You will have to use

!!

way too often, and do not even see the number that it couldn’t parse. On the other hand, when handling user input, it could be nice to have nullable variant, so that you can fail gracefully, with some default, or better exception, or something. Too bad actual NumberFormatException doesn’t give us the reason of failure, so it’s not suitable for user feedback.

Good question to ask here is “okay, I got null from

toInt

, now what?” If you find it more often would be

s.toInt() ?: throw SomeException()

it wouldn’t be much better than throw it right away.

I see your point

Is it british-style response? simple smile

No it isn't

:)

I examined my code base, and in most cases it is '?: halt ("need a parameter x")'

So not very different from an exemption

The thing that i was frustrated about was that kotlin didn't warn me that an exemption may happen

On the other hand nothing too bad happend

And yes, .? and ?: are nicer than try catch ugly blocks

Q: is there any plan to add APIs for function composition, currying, partial application, flipping arguments, etc. to the stdlib?

@natpryce: like this? https://github.com/MarioAriasC/funKTionale

Yes. Was wondering if anything like that will make its way into the stdlib

what’s wrong with this library?

By the time we found it, we’d written a lot of them ourselves