[WIP] Add immutable array vc

[odersky]

This is an attempt to add immutable arrays as value classes over normal arrays. So far, this compiles only in dotty under PR #1906, but there is an ongoing discussion about its validity.

It should also be noted that the arrays defined here don't have an immutability guarantee. It's just that they don't offer mutation operations themselves. So, maybe they should rather be a collection.Array instead of a collection.immutable.Array.

[dwijnand]

I would call this is an "unmodifiable array" rather than an "immutable array", and definitely not put it in the immutable package.

[julienrf]

After discussing with @densh, I think it might be interesting to bring efficient head/tail decomposition to immutable.Array by additionally storing the actual start and end indices to use of the underlying array. This way, tail could be implemented like this: def tail = if (isEmpty) throw Unsupported else new immutable.Array(underlying, start + 1, end). But that would be incompatible with a value class… What do you think of this idea, though?

Also, I think we could have more efficient implementations of map and some other methods of Array because we often know in advance the size of the resulting collection (so, we don’t need to go through a growing buffer). But, I definitely have to push a benchmark to check that…

[julienrf]

Why do we need to go through an implicit conversion here rather than making immutable.Array extend immutable.ArrayOps?

[sjrd]

The efficient head/tail decomposition is only possible if it is truly an immutable array (not a read-only view of an array).

IMO we need both truly immutable array (in collection.immutable) and an efficient read-only view of an array (in collection). The former is not that inefficient either. Only the first "wrapping" from an array needs copying. Subsequent operations do not need more copying than the read-only view version.

[odersky]

The discussion in scala/scala3#1905 shows that things are not so simple. We would have to await major implementation changes for value classes to make this approach work.

If we do not insist that immutable arrays have the same representation as mutable ones, then
I believe the existing ArrayView is already pretty good, and has the advantage of simplicity. Like the current PR there's no guarantee of immutability, but the view itself is readonly.

[odersky]

After discussing with @densh, I think it might be interesting to bring efficient head/tail decomposition to immutable.Array by additionally storing the actual start and end indices to use of the underlying array. This way, tail could be implemented like this: def tail = if (isEmpty) throw Unsupported else new immutable.Array(underlying, start + 1, end). But that would be incompatible with a value class… What do you think of this idea, though?

I think this a great idea, but I would look at ArrayView as the right basis to do this.

[odersky]

In fact ArrayView already supports efficient head and tail since it is an IndexedView.

[szeiger]

ArrayView in master doesn't have efficient tail. It only wraps an array without an extra start index and length. ArrayBufferView has those. I see no reason why we would want to keep a separate ArrayView. In #2 I unified them.