you can't write a generic one of course since you can't have a function with a variable number of type params

I tired to use Dagger with Kotlin. I noticed that class are not generated. When I run Gradle in command line I get "'kapt.generate stubs' is not used by the 'kotlin-kapt' plugin". Anyone know why?

is

this::method

actually leaking when called in

init

or

constructor

blocks?

@michaelzinn You can also use the

@JvmSuppressWildcards

annotation like so:

List<@JvmSuppressWildcards List<String>>

.

Does

kotlin-stdlib-jre8

always include

kotlin-stdlib-jre7

, and if so, does it do any harm to use

excludes

to leave out

jre7

from the

runtimeClasspath

?

runtimeClasspath - Runtime classpath of source set 'main'.
+--- org.slf4j:slf4j-api:1.7.22
+--- org.jetbrains.kotlin:kotlin-stdlib-jre8:1.1.4
|    +--- org.jetbrains.kotlin:kotlin-stdlib:1.1.4
|    |    \--- org.jetbrains:annotations:13.0
|    \--- org.jetbrains.kotlin:kotlin-stdlib-jre7:1.1.4
|         \--- org.jetbrains.kotlin:kotlin-stdlib:1.1.4 (*)

@lab Something like this?

val filtered = (0..list.lastIndex).asSequence()
    .filter { it in indexes }
    .map(list::get)
    .toList()

(I haven't tested it)

@karelpeeters @Ruckus the purpose of the trie was for indexing and searching apps in an Android launcher. (The repo is at https://github.com/louisgv/janusLauncher) I'm refactoring the trie to return a

List<AppModel>

(AppModel store all necessary info of an Android app). Here's the

getLeaves

method that I'm testing around with:

class WakeTrieNode (val key: Char?,
                    val value: AppModel?,
                    var isLeaf: Boolean,
                    val children: MutableMap<Char, WakeTrieNode> = mutableMapOf()) {

    fun getLeaves(): List<AppModel>{
        return if (isLeaf && value != null) listOf(value)
        else children.flatMap { child ->
            child.value.getLeaves()
        }
    }
}

Is there a better way to do this? The part where it return listOf(value) seems bad to me.

contains

checks for an exact match, so it doesn't really fit your use case.

@joshuaavalon works for me, except for one known proguard bug which forces me to compile kotlin with target jvm-1.6

is it possible to do something like

abstract class A<T : S> : T

where

T

is an interface?

I’m getting a PROPERTY_WONT_BE_SERIALIZED warning when using the new Parcelize annotation.

@Parcelize
class ExampleClass : Parcelable {

    var id: Long? = 0
    var name: String? = null
    var tagName: String? = null
    var enabled: Boolean = false

Do my properties have to be constructor parameters?

I’m getting an error that I can find no explanation for at all in the docs or on google generally: “Violation of Non-Expansive Inheritance Restriction for io.requery.query.LogicalCondition.” What is the Non-Expansive Inheritance Restriction?

ugh i just got bit by the difference between

val X = blah()

and

val X
  get() = blah()

Maybe a warning from the kotlin plugin on vals defined as properties with expressions derived from functions would be nice

no, it doesn't. Nothing to do with vararg, it seems.

fun foo(bool: Boolean = true, string1: String) {}
fun main(args: Array<String>) {
   foo("b") // does not compile
}

Hi! We have an open call for papers for the MBLTdev Conference which takes place on October 27 in Moscow. We are searching for the Kotlin experts to deliver a talk and will be happy to award the best submission with a travel grant. Learn more here: https://goo.gl/forms/FE64ZDzvBSrc5OZP2

Hi guys! Is there a way to use expressions with string interpolation? This looks horrible:

it.Specification?.let {
                                with(it) {
                                    val mk = (make ?: "")
                                    val md = model ?: ""
                                    "$mk $md"
                                }
                            }

hi again, how do you guys/girls write tests for an infix function inside a builder

Or maybe you can run trough it with a debugger and check the exact classes of everything involved?

any recommendations for http request library with asynchronous requests? Is Fuel (https://github.com/kittinunf/Fuel) a good one?

Is there a function in the standard lib that could help in taking a list of doubles and consume 2 elements each time? I want to convert a flat list of lat-lon doubles to LatLng instances.

Is it a bug that reified inline functions are marked as private for java callers?

Why I can't use Java's static getters and setters as properties (e.g.

System.getProperties()

->

System.properties

)?

http://kotlinslackin.herokuapp.com/ is down

Huh.. How do you do multiconditional for loops?

Hi all. I ran into an interesting little problem with type inference producing a counter-intuitive result. It's not a bug, but it's maybe an example of an undesirable side-effect of the way things are specified right now.I was playing around with JKid, and writing a new unit test, and I had code like this:

private val df = SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS zzz")
   private val value = TimeWithZone(df.parse("2017-08-18 17:25:26.632 PDT"))    

    @Test fun testDeserialization() {
       println("deserialize gives " +  deserialize(json))
       assertEquals(value, deserialize(json))
    }

This failed with a ginormous stack backtrace, deep in the bowels of reflection, telling me it couldn't find a field of TimeWithZone. The fix is compact enough:

println("deserialize gives " + deserialize<TimeWithZone>(json))

OK, so in the assertEquals, type inference is used to make the call of deserialize<Any> into a call of deserialize<TimeWithZone>, whereas in a println, it's not. Reasonable enough, I guess, but a little non-obvious. Intuitively, I just don't expect an expression to change meaning based on where it's used. In this case, I'd actually rather that type inference hadn't made the assertEquals call work, and instead had forced me to type deserialize<TimeWithZone>(...) in the first place. I'm sure there's a case to be made for the more eager type inference that Kotlin has today, but I just thought I'd throw this out there as maybe an unintended and undesirable side-effect. I could see this behavior causing a lot of confusion, particularly for someone coming from a less statically-typed background.

I have a problem with getting getter annotation from property reference. Here is annotation:

class A {
    @get:Arg val a: Int by BoundToValueDelegateProvider()
}

Inside

provideDelegate

I have property reference

operator fun provideDelegate(
        thisRef: Any?,
        prop: KProperty<*>
): ReadWriteProperty<Any, T> {
    val annotation1 = prop.getter.findAnnotation<Arg>() // This is null
    val annotation2 = prop.javaGetter?.getAnnotation(Arg::class.java) // This is null too
    // ...
}

It this bug or expected behavior?

When are coroutines going to be finalized?