expand scope of scala-collection-compat to include non-collection parts of 2.13, or make a new lib?

[SethTisue]

this was previously discussed at #151

a start was made at doing it in a separate repo at https://github.com/bigwheel/util-backports

I don't have a strong feeling of whether it ought to go in this repo, or whether it ought to go in a separate repo and artifact. the name scala-collection-compat is unequivocal

[SethTisue]

some excerpts from a recent discussion about this with @nrinaudo on Gitter, starting at https://gitter.im/scala/contributors?at=5d0571fd6f0ec85ade14a1cb 👍

the example here is the question of to deal with Either#right being deprecated in 2.13, but needed in 2.11 to get right-bias

Nicolas Rinaudo @nrinaudo 00:32
it’s problematic when 2.11 Either isn’t biased and 2.13 RightProjection is deprecated...

Seth Tisue @SethTisue 08:46
consider using ghik/silencer to silence only selected warnings
also consider not even aiming to enable -Xfatal-warnings on all of the versions you cross-build for. in the stdlib, we aim to enable 2.11-2.12-2.13 cross-compilation in most cases, but without warnings? not a goal.

Nicolas Rinaudo @nrinaudo 10:01
silencing warnings: that's a valid point in general, but maybe not here specifically - I want deprecation warnings, since these will eventually result in code that don't compile when the deprecated member is gone. And I can't really get the compiler to ignore that Either isn't right biased in 2.11

Seth Tisue @SethTisue 10:20
re: the deprecation of the right projection on Either, I don't recall the argument about cross-compilation with 2.11 being made at the time we did the deprecation, though I'd have to revisit the PR to be sure. perhaps a PR that un-deprecated .right in 2.13.1 (with an appropriate Scaladoc addition that explains the method is only recommended when cross-compiling), would be accepted.
in your own project, perhaps you could work around it by defining an extension method, with version-specific sources, that calls .right on 2.11 but is a no-op on 2.13?

Nicolas Rinaudo @nrinaudo 10:26
that's exactly what I'm doing, yes. My follow up point was that it might be something that you'd want to put in collection-compat, or a more generic "2-13-compat" library?
Surely I'm not the only one that's running in the problem?
and I honestly would prefer if it stayed deprecated - I'm all for getting rid of this type of things and making the language more uniform

Seth Tisue @SethTisue 10:28
Surely I'm not the only one that's running in the problem?
I think I've heard it approximately one other time, so far.
I'm increasingly seeing open source projects dropping 2.11 from their crossbuilds, anyway

Nicolas Rinaudo @nrinaudo 10:29
that's certainly another option

Seth Tisue @SethTisue 10:33
personally I'd be fine with the scope of scala-collection-compat being expanded in this way, >Julien was as well. (but nobody should be waiting around for Lightbend or the Scala Center to tackle it ourselves.)
from time to time people ask in this channel if there's some entry-level open-source work they could do in scala/*, this is one answer

Nicolas Rinaudo @nrinaudo 10:34
I wasn't implying that this should be the case, although there would need to be sort some of guidance, given that the project's scope would change and maybe its name should as well

I said "I'd be fine...", but I'm having second thoughts given that the name scala-collection-compat is so clear and unequivocal. in any case, it would be awesome if this happened in some form or another.

[nrinaudo]

Couldn't there be a 2.13-compat lib that depended on collection-compat?

[sjrd]

scala-stdlib-compat to have a name that's not dependent on the version number?

[dwijnand]

Perhaps name the project scala-compat so it can include a number of different compatibility solutions.

As a side-benefit, perhaps scala-rewrites should be merged into here rather than the collection rewrites being exported and merged into scala-rewrites (aka lightbend-labs/scala-rewrites#3).

[ekrich]

I think maintaining a library like this for the stdlib is a really good idea as it makes it really easy to upgrade your code to the latest version. When 2.14 is released then support for 2.11 could be dropped. It would also be nice if it helped with the lines, linesIterator issue with JDK8/11 as well to help with JDK upgrade issues.

[NthPortal]

if someone creates a project for this, I'm happy to help backport things.

[SethTisue]

#312 is merged so the door is now open on this

closing, but also made a new ticket just about maybe renaming the lib: #317

[SethTisue]

feel free to open tickets — or send pull requests — on specific desired additions such as the ones mentioned in various comments above

[NthPortal]

I'm already working on backporting scala.util.Using (working on the tests)