kotlinlang #stdlib

println(listOf(1, 2, 3).hashCode())
println(listOf(1, 2, 3).hashCode())
println(listOf(1, 2, 3).toIntArray().hashCode())
println(listOf(1, 2, 3).toIntArray().hashCode())

which gives

Copy code

05/17/2016, 7:53 PM

Equals and hashCode use identity for primitive arrays

orangy

05/17/2016, 7:54 PM

Try using

Arrays.hashCode

Arrays.deepHashCode

orangy

05/17/2016, 7:55 PM

It’s not Kotlin’s feature, it’s JVMs

holgerbrandl

05/17/2016, 8:10 PM

thanks! Imho by wrapping them (ie

IntArray

DoubleArray

, etc) behind a

kotlin.collections.Iterable

like interface, their primitive nature becomes too hidden to justify sticking to Java conventions here. However, I see the point that kotlin also wants to stay consistent with java where possible, so maybe you could add an inspection to warn

IntArray.hashCode()

(etc.) users about the danger? This should not be too hard since there's a "hashCode() called on Array" inspection already for java.

👍 5

ilya.gorbunov

05/24/2016, 4:49 PM

We'd like to announce first two proposals for a new API in stdlib: https://github.com/Kotlin/KEEP/issues?q=is%3Aopen+is%3Aissue+label%3Astdlib You're welcome to join to the discussion of these proposals.

K 2

ilya.gorbunov

05/24/2016, 4:55 PM

The discussion will last for about two weeks and after that we'll decide whether to take or reject them.

ilya.gorbunov

05/24/2016, 4:57 PM

If you have an idea for a new API you can create your own proposal based on this template https://github.com/Kotlin/KEEP/blob/master/proposals/stdlib/TEMPLATE.md and file it as pull request to KEEP repository: https://github.com/Kotlin/KEEP

orangy

05/24/2016, 5:39 PM

<!here|@here>: if you are interested in giving feedback and improving Kotlin stdlib, please pay attention to the announcement above.

ilya.gorbunov

05/24/2016, 6:33 PM

@ilya.gorbunov pinned a message to this channel.

hastebrot

05/24/2016, 6:45 PM

would a running index for KEEPs make sense?

evanchooly

05/24/2016, 7:11 PM

in progress

active

rejected

orangy

05/29/2016, 10:33 PM

https://youtrack.jetbrains.com/issue/KT-12539 Please add your use-cases.

bamboo

06/02/2016, 5:11 PM

How would a PR making

Lazy<T>

extend

java.util.concurrent.Callable<T>

be received?

bamboo

06/02/2016, 5:12 PM

(it’s good for interoperability with the Java ecosystem and Gradle more specifically)

bamboo

06/02/2016, 5:13 PM

call() = value

ilya.gorbunov

06/02/2016, 6:01 PM

@bamboo: What are the pros of such step compared to wrapping Lazy in a Callable with the following extension?

Copy code

fun<T> Lazy<T>.asCallable() = Callable { value }

bamboo

06/02/2016, 6:39 PM

Consider a call to a method

from(valueSource: Any)

With `Lazy<T> : Callable<T>`:

Copy code

from(lazy { expensive }) // idiomatic Kotlin, user can’t forget a step, either is lazy or not

With `asCallable`:

Copy code

from(lazy { expensive }.asCallable()) // non idiomatic, user might forget asCallable() and get runtime exception

bamboo

06/02/2016, 6:40 PM

in reality

asCallable()

wouldn’t be needed because one can write:

Copy code

from(Callable { expensive })

bamboo

06/02/2016, 6:41 PM

in my mind it’s really about idiomatic versus non-idiomatic Kotlin

ilya.gorbunov

06/02/2016, 6:54 PM

Making

Lazy

extend

Callable

would introduce binary incompatibility for those who have already implemented Lazy in their APIs, so I'm afraid this train has gone.

ilya.gorbunov

06/02/2016, 7:01 PM

Regarding the example with

from(source: Any)

function, I doubt that having a function that accepts

Any

and behaves differently based on the actual type of

source

is idiomatic in a statically typed language such as Kotlin is.