```fun foo(range: ClosedRange<*>) {} fun foo(range: OpenEndRange<*>) {} foo(5..12)``` gets ```Overl...

# language-evolution

[CLOVIS]

fun foo(range: ClosedRange<*>) {}
fun foo(range: OpenEndRange<*>) {}

foo(5..12)

gets

Overload resolution ambiguity between candidates

because IntRange is both ClosedRange and OpenEndRange … It's a shame because the behavior would be exactly the same no matter which one the compiler chose.

Is there another solution other than creating a new overload of foo for ByteRange , ShortRange , IntRange and LongRange , and also all the unsigned ones?

[CLOVIS]

Ah, found an ok solution: adding a third overload

fun <R> foo(range: R) where R : ClosedRange<*>, R : OpenEndRange<*> {
    foo(range as ClosedRange<_>)
}

This one eats all the cases that implements both and redirects it to the first one. I'll assume people who write types that are both open and closed range have checked that they both have the same results.

[Klitos Kyriacou]

That looks good to me. But I've never seen the underscore used like that, in range as ClosedRange<_> - how does it differ from an asterisk?

[CLOVIS]

<_> means "hey, compiler, you're smart enough, figure out what should go there"

[CLOVIS]

In this specific example I think only * is allowed though, sorry for that