No BuildFrom for IArray

[bishabosha]

Compiler version

3.3.1

Minimized code

def diffs(ns: IArray[Long]): IArray[Long] =
  ns.lazyZip(ns.tail).map((a, b) => b - a)

Output

Cannot construct a collection of type C with elements of type Long based on a collection of type IArray[Long]..
I found:

    scala.collection.BuildFrom.buildFromIterableOps[CC, A0, A]

But method buildFromIterableOps in trait BuildFromLowPriority2 does not match type scala.collection.BuildFrom[IArray[Long], Long, C]

where:    C is a type variable with constraint <: IArray[Long]

Expectation

compiles

[SethTisue]

something someone from @scala/collections might like to tackle?

[bishabosha]

Another annoyance is IArray doesn't have a Factory so no .to(IArray)

[bishabosha]

with advent of code 2024 I am again bitten here, relevant methods to copy/cast the Array implementation from:

• scala.collection.BuildFrom.buildFromArray
• Array.toFactory

[Ichoran]

I wouldn't bother with IArray for normal use. It's nice in principle that one can declare that it should be immutable, but in practice there's so much friction with the rest of existence that it's not really a win. Obviously if anyone wants to try to get it better integrated, that's fine, but I think basically it's an idea that doesn't pan out as well in practice as one might hope.

[bishabosha]

what way do you mean? is that more a general statement on opaque type wrappers? or specifically an issue with IArray?

[Ichoran]

Array is really deeply enmeshed with the entire ecosystem, both in Scala and Java. Because of that, the surface area that you need to cover to get an IArray that works comparably is quite large, and there remain many points of friction.

In cases where you have opaque types where the point is to generate a different interface, that isn't as much of an issue: you don't want to pick up the behavior of the underlying type. That's the point!

But with IArray, you want to pick out a small subset of a huge number of behaviors of Array that you don't obey (the mutable ones), and everything else you want to work the same (much like mutable.Seq vs immutable.Seq). It's a ton of work.

Thus, I think pragmatically, the better approach is just to accept Array as a special snowflake, and maintain appropriate caution. There are lots of areas where the type system can't help you. Even though it might be able to here, I think it's easier, usually, to declare that this is a case where it could but isn't worth the effort.

In fact, I'd expect the easier interface to be having a general-purpose box Imm[A] that marks that whatever is inside shouldn't be mutated any longer.

But I have odd preferences sometimes. Maybe IArray is the way to go for not-like-me people. But I tried it pretty extensively, and found that for me the cognitive overhead of maintaining two interfaces was considerably worse than the cognitive overhead of just being careful around Array.

[bishabosha]

In fact, I'd expect the easier interface to be having a general-purpose box Imm[A] that marks that whatever is inside shouldn't be mutated any longer.

coming soon™️ with caprese https://infoscience.epfl.ch/entities/publication/0d93a16f-f957-4c40-99db-43ed1301dff3

[ritschwumm]

@Ichoran funny - i am quite happy with IArray. almost everything i need, and none of the disconcerning
mutability :)

[Ichoran]

@ritschwumm - Well, like I said, my tastes do not match everyone's tastes!