I often find I end up creating a pair of methods on a class -

foo(vararg elements: Bar)

and

foo(elements: List<Bar>)

because sometimes it's convenient to use varargs, but sometimes I have a List and

*elements.toTypedArray()

is a bit of a faff. I tend just to make one delegate to the other - but I just encountered a case where it was pure waste to allocate the extra List or Array, as all I then did was iterate over it. Is there any way to abstract over

Array

and

List

to treat both as the same sort of thing?

Is array.asList() out of the question? since that just wraps the array (as opposed to toList which allocates a new chunk of memory to copy the elements into). Or perhaps have doFoo take an IteratorFoo and pass it array.iterator() or list.iterator()

It was the extra allocation of an object to wrap the array as a List or Iterator I was vaguely hoping to avoid - that's what I normally do, it just occurred to me that I could literally copy the method and void it entirely, but at the expense of the duplication.

Taking a page out of the FP book, here's a typeclass-esque solution: (I'm avoiding using iterators on purpose. Bear in mind that normal array and list iteration is optimised, but this version wouldn't be)

abstract class ListLike<in L, out E> {
  abstract operator fun L.get(index: Int): E
  abstract val L.size: Int
  
  final inline fun L.forEach(block: (E) -> Unit) { for(i in 0..size) block(i) }
  
  object ListImpl: ListLike<List<*>, Any?>() {
    override operator fun List<*>.get(index: Int) = this[index]
    override val List<*>.size = size
  }
  object ArrayImpl: ListLike<Array<*>, Any?>() {
     override operator fun Array<*>.get(index: Int) = this[index]
    override val Array<*>.size = size
   }
  
}

(Code untested because I'm on mobile) Simply just bring in the apt XImpl instance using

with

, and the function with the real implementation should have

ListLike<L, E>

as its receiver (ideally a context receiver if you're on the bleeding edge), or it can just take it as a parameter and bring it in itself. You might need some unsafe casts here or there, which can simply be wrapped in a function on ListLike's companion.

after https://youtrack.jetbrains.com/issue/KT-43871 you could choose to keep only the

List

version, and make the callers write

foo([1, 2, 3])

I was so sure that Array<T> implements Iterable<T> but it doesn't 😮🤯 https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-array/

arrays are an intrinsic part of the JVM's object model which are deeply special. Kotlin can't change that

good point. Purely academical "hindsight is 20/20" question: would it have been a better idea to make

varargs

a List instead of an Array? Was an Array chosen for historical reasons or for efficiency or is there another reason?? @Rob Elliot so

List

and

Array

don't have a joint interface, but both can produce an

Iterator<T>

, so you could use that as a unifying solution!?! You won't have a

for-loop

(that one works on

Iterable<T>

) but you do have

forEach

and

map

.

Was an Array chosen for historical reasons

I believe it was for interoperability with Java's varargs, which are arrays ; so you can call Java vararg functions from Kotlin and the reverse transparently

@CLOVIS yes, of course. makes sense 🤷‍♂️

> so

List

and

Array

don't have a joint interface, but both can produce an

Iterator<T>

, so you could use that as a unifying solution!?! You won't have a

for-loop

(that one works on

Iterable<T>

) Funnily enough, the

for

loop works on Iterators too, even though the docs say it needs an Iterable: https://pl.kotl.in/3f7a7Dh0_

fun main() {
    for (c in arrayOf('a', 'b', 'c').iterator())
    println(c)
}

which, fun fact, literally just returns itself