eski: Compile them with different module names

That’s a quick fix, but what if the two dependencies are from different owners that don’t even know about the other project?

Maybe it’s on the android gradle plugin to handle merging the two files.

import java.util.ArrayList

fun main(args: Array<String>) {
    val names = listOf<String>()
    val results = names.reduce { name1, name2 ->
        "${name1} ${name2}"
    }
    print(results)
}

Exception in thread "main" java.lang.UnsupportedOperationException: Empty iterable can't be reduced.

at Simplest_versionKt.main(Simplest version.kt:16) WTF…. The compiler not have any error at compiler time…… when I have a exception.

@eski, funny enough, I just mentioned getting that error from Anko! https://kotlinlang.slack.com/archives/anko/p1458687269000009 Quite bothersome. Am I going to have to rename my module just to avoid the name clashing with anko (I think we both use

common

)?

I’m trying to figure out a good way to rename the file name rather than renaming the module

I’m guessing this will come up a lot as more libraries are built with kotlin. Module names aren’t meant to be unique at all. In my case, I have “android” as a child module of the platform-generic library. Which clashes with another library where I do the same thing.

Those files look pretty darn simple, so it shouldn’t be too hard to make the merge task “kotlin aware"

Agreed, when I realized that it was because of "common", my first reaction was to think that I was shocked that this didn't come up sooner, because module names are usually pretty standard across projects

@jian: why do you consider it a WTF? it would be really great if a compiler could detect all possible errors in a program at compile time, but this has been mathematically proven to be impossible

your case is no different from

””[0]

which will also fail with an exception at runtime

Why indeed? I would expect a "delegate mismatch: setter is not delegateed" https://kotlinlang.slack.com/archives/general/p1458690584001491

For example

var foo: Int by lazy {8}

rightfully complains

@mitchwongho: thanks for the link! I see this library for the first time, and just add it to http://kotlin.link/

question: is there a gradle autogenerate kotlin project task like for java?

@dierre "configure Kotlin" in IJ

Kotlin 1.0.1: hotfix update is now available! Issues fixed in update: https://youtrack.jetbrains.com/issue/KT-11468, https://youtrack.jetbrains.com/issue/KT-11478. In Maven / Gradle, please use version 1.0.1-1 for Kotlin artifacts.

Knowing KType, is it possible to get KClass?

@aaverin: it’s complicated, I’ll explain in #C0AVAB92L

@mglukhikh: why 1.0.1-1 and not 1.0.2?

appending

-1

makes it look like a packaging fix, IMO

We will probably discuss this once more. But at the moment numbers like #.#.#-# are used as hotfixes for the version #.#.#, just to distinguish hotfix from regular minor release.

I see. Perhaps I’ve just been using Linux for so long it stands out; most distros signify a packaging fix (as opposed to the contents of the package) with the

-#

suffix. I’ve never understood the reasoning behind separate schemes for hotfixes as opposed to normal patch versions; a hotfix is still a patch release and, especially considering the importance that “hotfix” implies, should be presented like any other patch release would be.

^^ @abreslav ^^

Our policy is: * 1.0.1 and all odd suffixes — maintenance/bug fix update * 1.0.2 and all even suffixes — non-language features (features in IDE, build tools, etc) * 1.0.X-1 — hot-fix update * 1.1 — language features

that seems quite complicated. the distinction between maintenance/bugfix update and non-language features seems like an internal policy decision that isn't really worth reflecting in the version number, which may end up being parsed by non-JB programs

is 1.0.X-1 compatible with semver?

does that mean you would release 1.0.1 and then 1.0.3 if there was no non-language features?

and then if a 1.0.4 comes along you might do 1.0.6 after if there were no bug fixes?

also, are there ever releases without bug fixes?