maybe I can open a feature request on the kotlin p...

# announcements

[groostav]

maybe I can open a feature request on the kotlin plugin to flag any set operators on Collection<A> op Collection<B> -> Collection<Serializable> as suspicious?

[Nir]

This is just a result of inheritance and covariance though, isn't it

[Nir]

I don't think there's anything unexpected happening here

[Nir]

Ah, you're just asking for a warning

[groostav]

yeah exactly, its as intended, its just unfortunate

[Nir]

The thing, is, as soon as you use the result of that expression for anything, you'll almost certainly get a compiler error, no?

[groostav]

except if you use the monadic set combinators as I was

[Nir]

Hah, well 🙂

[Nir]

It may have delayed it, but I would still expect, that eventually, you'll do something where you actually expect to have, at least, a Collection<String>

[groostav]

that particular code more-or-less translates to

if((a - b - c).isEmpty()) { return validationFailure() }

[Nir]

Ah, I see

[Nir]

A great example

[Nir]

I wonder if there is any way to keep covariance useful, and avoid situations like these

[groostav]

I'm wondering how common it is to have these set operators yield a result of Set<Any> or similar and still be useful

[groostav]

actually

[Nir]

Well, this sort of thing is going to apply to pretty much all of the read-only binary collection operations

[groostav]

right but my brain isnt big enough for all of them

[groostav]

but subtraction has interesting implications for equality

[Nir]

Collection<Any> is probably almost always wrong, but I guess, where do you draw the line? The further "down" the type is the more likely it is to be correct.

[groostav]

if we just think about minus, then we could make some condition like:
given expr = Set<A> - Set<B>
then: A and B must share an implementation of equals

[Nir]

Yes, subtraction is especially bad.

[groostav]

im guessing that writing analysis to "find the least common ancestor implementation of equals on types A and B" is not a cheap question for the kotlin plugin to ask

[Nir]

Kotlin will already error out on comparing 2 unrelated types though

[Nir]

So now I'm wondering how this compiles

[Nir]

I guess, things like Set internallyuse .equals, and not ==

[Nir]

?

[groostav]

depends on the set implemnetation of course but AbstractSet does use deep equality

[groostav]

Treeset's require use of a comparator ofc makes this more complex

[Nir]

== and .equals are both deep equality

[Nir]

Ugh, == is the same as .equals for non primitive types, I didn't realize that

[Nir]

So things like listOf(5) == setOf(20) compile 😞

[Nir]

hmm, actually, just not sure anymore, need to check this out again later