summaryrefslogtreecommitdiff
path: root/build.xml
diff options
context:
space:
mode:
authorSimon Ochsenreither <simon@ochsenreither.de>2016-04-27 21:25:57 +0200
committerSimon Ochsenreither <simon@ochsenreither.de>2016-05-27 15:01:47 +0200
commit6e9faf5157132ad575c98e5a9a0919ac38b7beb8 (patch)
tree1230333b98544c28b26e7c9e55d7581c62f323bd /build.xml
parentf7b575de222befb2cd1dd2f676e177ece8a1d234 (diff)
downloadscala-6e9faf5157132ad575c98e5a9a0919ac38b7beb8.tar.gz
scala-6e9faf5157132ad575c98e5a9a0919ac38b7beb8.tar.bz2
scala-6e9faf5157132ad575c98e5a9a0919ac38b7beb8.zip
Right-bias Either
- Add operations like map, flatMap which assume right-bias - Deprecate {Left,Right}Projection - Deprecate left and right in favor of swap - Add contains, toOption, toTry, toSeq and filterOrElse - toSeq returns collection.immutable.Seq instead of collection.Seq - Don't add get There are no incompatible changes. The only possibility of breakage that exists is when people have added extension methods named map, flatMap etc. to Either in the past doing something different than the methods added to Either now. One detail that moved the scales in favor of deprecating LeftProjection and RightProjection was the desire to have toSeq return scala.collection.immutable.Seq instead of scala.collection.Seq like LeftProjection and RightProjection do. Therefore keeping LeftProjection and RightProjection would introduce inconsistency. filter is called filterOrElse because filtering in a for-comprehension doesn't work if the method needs an explicit argument. contains was added as safer alternative to if (either.isRight && either.right.get == $something) ... While adding filter with an implicit zero value is possible, it's dangerous as it would require that developers add a "naked" implicit value of type A to their scope and it would close the door to a future in which the Scala standard library ships with Monoid and filter could exist with an implicit Monoid parameter.
Diffstat (limited to 'build.xml')
0 files changed, 0 insertions, 0 deletions