Rename `to` to `as`

[julienrf]

I propose that we rename the to method to as, to convert a collection into another (or force a view).

List(1, 2, 3).as(mutable.ArrayBuffer)

This would have the following advantages:

• no conflicts with the to operation of SortedSet (which has currently been renamed to rangeTo, see #546)
• cross building and migration will be simpler: we can just add the as operation to the scala-collection-compat library, like we did in some other cases, instead of relying on complex implicit conversions
• we could even re-introduce a deprecated to method for backward source compatibility

[szeiger]

What conflict is there with SortedSet.to? It looks like the 2 signatures are different enough to be able to coexist.

IMHO to is more appropriate if you only supply a type constructor or factory, i.e. to[List] or to(List) but as[List[Int]] (but maybe that's just because of the strong precedent set by the existing to method).

[julienrf]

I don’t remember which one exactly but there was a problem when having two to methods, that’s why we had to rename SortedSet#to to SortedSet#rangeTo. I guess it has something to do with the fact that to(List) requires List to be implicitly converted to a Factory[X, List[X]] (in presence of two alternative to, maybe the implicit conversion is not even tried).

[odd]

FWIW, I think to is clearer since modifications to the returned collection doesn't affect the original (or vice versa). If on the other hand modifications to one would affect the other, I'd prefer as since (to me at least) "as" signals projection rather than transformation or direction (of course this distinction is only meaningful for mutable collections).

I'm not a native English speaker though, so I might be completely wrong on this one.

[Ichoran]

I agree with Odd, especially since there is some precedent in as being a lightweight view (asInstanceOf, asJava, etc.) whereas to has always been a heavyweight copy at least with collections.

I would not recommend switching from to to as.

[julienrf]

Do you have another (short) name suggestion?

[odd]

Seeing that the operation really takes a Factory and not the target type directly (although all the collections companion objects are such factories, you could provide your own), one could take inspiration from mkString (which produces a string from a collection) and call it mk / make / makeWith (other alternatives are build / buildWith / produce / produceWith). Another alternative is to focus on the conversion aspect and call the operation convert/convertTo/convertWith. But none of those seems as nice as the current to though (if the current to is going to be reintroduced however that doesn't matter as much).

[Ichoran]

I don't have a suggestion aside from leaving the name as is. Everyone knows to already. If the compiler for some reason can't distinguish between the different flavors of to, I think the place to work on it is the compiler. If it's just because both things erase to to(Object), can't you do the standard implicit disambiguation thing?

[lrytz]

For SortedSet, I find the name (rangeTo) better anyway. We should rename from to rangeFrom. It's just unfortunate that we cannot deprecate to, but give it a new meaning immediately. But I think the SortedSet method is used rarely enough, it doesn't justify a big change (finding an alternative name for to).

[julienrf]

Actually I was wrong, it is possible to have both to methods in Scala 2.13, and the overload resolution mechanism can handle the implicit conversion if any.

[julienrf]

@szeiger I remember you proving that it is possible to have both to methods in 2.13. Is this change PRed somewhere?