Sure, it may work fine in some cases. And then in ...

# announcements

[karelpeeters]

Sure, it may work fine in some cases. And then in others it doesn't, eg.

data class Foo(var x: Int)

fun main(args: Array<String>) {
    val f = Foo(3)
    val s = mutableSetOf(f)
    f.x = 7
    println(s == setOf(Foo(7)))
}

on try.kotlinlang.org.

[Andreas Sinz]

Set != MutableSet

[Andreas Sinz]

interesting, it works with Set, but not with MutableSet 🤔

[pavel]

it works with Set on JVM but not on JavaScript 🙃

[karelpeeters]

Aren't they both HashSet behind the scenes?

[pavel]

No

[pavel]

public fun <T> setOf(element: T): Set<T> = java.util.Collections.singleton(element)

[pavel]

public fun <T> mutableSetOf(vararg elements: T): MutableSet<T> = elements.toCollection(LinkedHashSet(mapCapacity(elements.size)))

[karelpeeters]

Well doesn't really matter even, the point is that it sometimes randomly fails.

[pavel]

👍

[karelpeeters]

I'll spend some time finding a hashset - hashset equals that fails simple smile

[pavel]

data class Foo(var x: Int)

fun main(args: Array<String>) {
    val f = Foo(3)
    val g = Foo(4)
    val s = setOf(f,g)
    f.x = 7
    println(s == setOf(Foo(7), Foo(4)))
}

[pavel]

that fails

[pavel]

I would expect it to succeed every time on JVM for a single element set and fail for multielement sets

[Dico]

I once submitted a bug for java.util.HashMap because if you mutate the keys, you can't remove it with the iterator. I argued that if you iterate all the elements and call remove for each one, the map should be empty (assuming no concurrent stuff going on) no matter what. I guess it's similar to this - you shouldn't mutate elements, but to what extent should a collection function if it does happen? Bug was fixed - there was another reason - but still.

[Dico]

There are some things that might still work if you mutate object in the set - for example it might still be returned from the iterator. But contains check breaks completely.

[Dico]

Why do you think it would work for single element sets?

[pavel]

because the implementation is public fun <T> setOf(element: T): Set<T> = java.util.Collections.singleton(element)

[Dico]

ah, makes sense

[pavel]

with this implementation it doesn’t have much choice

[Dico]

singleton method name always annoys me