Is there a way to circumvent overload resolution ambiguity on the following two functions without gi...

# getting-started

[andylamax]

Is there a way to circumvent overload resolution ambiguity on the following two functions without giving the functions different names,

class Zipped<out T>(val value:T)

// function one
fun <T,R> Zipped<T>.map(mapper: (T)->R): Zipped<R> {
  // . . .
}

// function two
fun <T,R> Zipped<Zipped<T>>.map(mapper: (T)->R) : Zipped<R> {
  // . . .
}

fun main() {
  val zipped: Zipped<Zipped<Int>> = Zipped(Zipped(2))
  val result = zipped.map { "zipped value: $it" } // when calling this function?
}

[Vampire]

Is "one" even valid? it gives two type args.

[Vampire]

But I guess you meant Zipped<T>.

[ephemient]

they have conflicting JVM signatures so you need some way to keep them separate, such as putting them in separate files or using @JvmName to rename them

[ephemient]

@JvmName("zippedMap") fun <T, R> Zipped<T>.map(mapper: (T) -> R): Zipped<R> = ...
@JvmName("zipped2Map") fun <T, R> Zipped<Zipped<T>>.map(mapper: (T) -> R): Zipped<R> = ...

[andylamax]

@Vampire yes, I meant Zipped<T>

[andylamax]

@ephemient let me try it out

[ephemient]

that being said, I don't think this is very good API design to have the shape of the result depend on the type of the input like this

[andylamax]

Either way, it still doesn't work. it fails with override resolution ambiguity when chainning

Zipped(0).map {
  it + 1
}.map {
  Zipped(it)
}.map { // override resolution ambiguity happens here
  it + 1
}

[Youssef Shoaib [MOD]]

I think giving function one an extra `unit: Unit = Unit`dummy parameter could do the trick

[ephemient]

being explicit on the last one

.map { it: Int -> it + 1 }

would make override resolution unambiguous

[Gleb Minaev]

It's not a solution for now, but I think marking the first declaration with kotlin.internal.LowPriorityInOverloadResolution should solve the problem.

Currently, (if I am not mistaken) it is considered to make the declaration public (KT-32618). Also I had a bit similar issue (KT-51899) with such ambiguity.