Add AnyTap, AnyPipe and Using #151
Conversation
Fixes scala/bug#5324 This implements an opt-in enrichment for any type called tap and pipe: ```scala scala> import scala.util.chainingOps._ import scala.util.chainingOps._ scala> val xs = List(1, 2, 3).tap(ys => println("debug " + ys.toString)) debug List(1, 2, 3) xs: List[Int] = List(1, 2, 3) scala> val times6 = (_: Int) * 6 times6: Int => Int = $$Lambda$1727/1479800269@10fbbdb scala> (1 + 2 + 3).pipe(times6) res0: Int = 36 scala> (1 - 2 - 3).pipe(times6).pipe(scala.math.abs) res1: Int = 24 ```
de-SAM, no trailing commas
martijnhoekstra
force-pushed
the
scala-library-compat
branch
from
1ba0e73 to
a7af40c
Compare
|
The scala-js failures depend on scala-js/scala-js@1fbc66e which is in master, but not published yet. The JVM 6 error is around AutoClosable, and I'm open to suggestions to that |
|
The more I think about this, the more I think it's a good idea (though it might also suggest renaming the artifact/repo to scala-2.13-compat). These things are really useful, and resource closing in particular is non-trivial and usually done wrong. |
|
@martijnhoekstra for JVM 6, there's |
martijnhoekstra
force-pushed
the
scala-library-compat
branch
2 times, most recently
from
bc27f53 to
47d7b29
Compare
|
@NthPortal I changed to Closeable, but at this point it's not clear to me why the original used AutoCloseable -- I did nothing special to change it, but if that's universally correct, why not have it on Closeable in 2.13.x (other than it being frozen)? |
martijnhoekstra
force-pushed
the
scala-library-compat
branch
from
47d7b29 to
742f928
Compare
|
Actually, I don't know how to do this. |
|
@martijnhoekstra because |
|
I agree that this would be good to extend the scope of scala-collection-compat to other parts of the scala-library. I’m not sure who is going to check that what we have in the compat library will stay consistent with the standard library and who is going to maintain the compat library in general? |
|
@julienrf from a high-level perspective, the invariant that should hold, I assume, is if some identifier I would sort of assume that the maintainers of this library are still going to maintain it if it expands from a collection-compat library to a general stdlib-compat library, but from your comment I get the vibe that's not a given 😬 For the functionality I implemented in this PR, I don't understand how the exception suppression works, so I think I'll need to cut |
|
Thanks @SethTisue for mention to me because I didn't know this useful library. |
|
(just a note for this that the state of |
|
With how much is in flux around both the features, and what's happening in the stdlib with this kind of stuff, combined with my sustained low bandwidth for OS work lately, I'm really out of the loop, and won't be able to bring this to a conclusion. |
To incite discussion.
2.13.x has nice new library additions, and it would be nice if we can offer source-compatibility beyond collections.
This cherry-picks
AnyTap,AnyPipeandUsingfrom 2.13 to compat.