@vandalko: what kind of issues?

I generate Java classes. Then when trying to use them in Dagger module, I get:

13:15:08.663 [INFO] [org.gradle.api.internal.tasks.compile.JdkJavaCompiler] Compiling with JDK Java compiler API.
13:15:08.929 [ERROR] [system.err] error: cannot access NonExistentClass
13:15:08.929 [ERROR] [system.err] class file for error.NonExistentClass not found
13:15:08.929 [ERROR] [system.err] Consult the following stack trace for details.
13:15:08.929 [ERROR] [system.err] com.sun.tools.javac.code.Symbol$CompletionFailure: class file for error.NonExistentClass not found
13:15:08.938 [ERROR] [system.err] warning: The following options were not recognized by any processor: '[kapt.kotlin.generated]'

do you have

kapt {
    generateStubs = true
}

yep

hm

i think i’ve run into this, i just cant remember when

can you share your gradle file?

and i’m guessing dagger isn’t throwing any issues in the compiler?

well, there is nothing special - I just use https://github.com/stanfy/helium/tree/master/gradle-plugin to generate Java classes from API spec, but when I'm trying to create a Dagger module which provides Retrofit interface, then I get the error above

I think I just have to wait for another kapt/kotlin-stdlib release simple smile

as we're talking about kapt here: I've been trying to run a simple annotation processor (taken from kotlin examples repo) as a separate module in my android project. However I'm not sure how I should configure app build.gradle; I've tried

kapt project(':kprocessor')

, I've tried

kapt files('libs/kprocessor.jar')

to no extent. Could anyone take a look at the repo and say what I'm doing wrong? https://github.com/arkadiytehgraet/kaptsample Does

kapt

even support this feature?

I have found the functions in stdlib preconditions.kt to be very useful. I was wondering about the possibility to add some function like checkNotNull, that will allow to parametrize the check with a lambda. Something like the following snippet

-.java

I like the idea. I rolled my own sth like that in the project. Would be great if it comes with stdlib right off the bat.

Those functions are certainly useful and there are probably way more functions that are useful that are common enough for some standard lib. However, I think it's wise to keep the std lib to a bare minimum. Motivation is of course startup times, memory consumption and method counts (android limit). Would be cool if we see some standard extension libs in the future, so people can decide for themselves what to add and what not.

Yes, the equivalent of guava. Call it kava, maybe?

kwi

kiwi is a nice name, too

I’d like Iterable<T> to have a toMap function with the signature:

<T,K,V> toMap(toPair: (T)->Pair<K,V>): Map<K,V>

What do you think?

As soon as we'd free

toMap((T) -> K)

we plan to introduce the former one with key-value pair selector.

kotlin.test.assertFailsWith

doc says "Since inline method doesn't allow to trace where it was invoked, it is required to pass a [message] to distinguish this method call from others." That's not true anymore, is it?

Unfortunately this is still true. When

assertFailsWith

fails (i.e. function being tested doesn't throw expected exception) it throws assertion exception from its body. In the stack trace of this exception you'll get line number in the file where assertFailsWith is defined, and not where it was called.

@ilya.gorbunov: what's the point of inlining

assertFailsWith

? In the green path the code inside the assertion throws an exception, which is very expensive (on jvm or anywhere else). Why would I care to inline everything else around, when a call invocation is cheaper than

throw

?

was going by and got curious

@voddan: it must be inlined to have reified type parameter

ok, there are different versions of this in

stdlib

. Thank you

@ilya.gorbunov: am I right that this problem would not exist if there would be something like

autoreified T

, which would automatically pass an additional java parameter

KClass<T>

without any Kotlin code needed?

Another option is something like ability to specify default value for

KClass<T>

parameter to be

T::class

. This default value could be available when T is known on call-site at compile time, otherwise explicit KClass would be required.

wow, that sounds like something I would not guess from a method declaration