Don't combine lefts on Xor and XorT combine #1034
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Resolves typelevel#888 I don't think there's really a _right_ answer here. Both methods of combining `Xor`s are straightforward and law-abiding. However, I think that since in pretty much every other context (including the `SemigroupK` instances), `Xor` does not combine failures and `Validated` does, it is less surprising behavior to not combine left values in `combine` methods for `Xor` and `XorT`. Some notes about related implementations: - Scalaz's respective methods (and semigroup instances) _do_ combine errors, so this is a deviation from that. - The `Semigroup` for `Either` in Haskell has doesn't combine values at all, but returns the first `Right` (if any), making it equivalent to the behavior of `orElse` and the `SemigroupK` instance for `Xor`. Since we have already decided to not go with `orElse`-like behavior for our `Option` semigroup, I'm inclined to not take this approach for `Xor`. See also typelevel#996 (comment)
| case Xor.Right(b1) => that match { | ||
| case Xor.Left(a2) => Xor.Left(a2) | ||
| case l @ Xor.Left(_) => l |
There was a problem hiding this comment.
Tiny thing, but let's call this left instead of l -- I think it reads a lot better.
|
Tiny style comment, but 👍 from me! |
|
👍 . This makes for {
x <- this
y <- that
} yield SemigroupInstance.combine(x,y)which make sense as you mostly want to use |
Per @non's suggestion.
Current coverage is 88.84%
@@ master #1034 diff @@
==========================================
Files 215 215
Lines 2726 2724 -2
Methods 2664 2663 -1
Messages 0 0
Branches 57 57
==========================================
Hits 2420 2420
+ Misses 306 304 -2
Partials 0 0
|
|
👍 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves #888
I don't think there's really a right answer here. Both methods of
combining
Xors are straightforward and law-abiding. However, I thinkthat since in pretty much every other context (including the
SemigroupKinstances),Xordoes not combine failures andValidateddoes, it is less surprising behavior to not combine left values in
combinemethods forXorandXorT.Some notes about related implementations:
errors, so this is a deviation from that.
SemigroupforEitherin Haskell has doesn't combine values atall, but returns the first
Right(if any), making it equivalent tothe behavior of
orElseand theSemigroupKinstance forXor.Since we have already decided to not go with
orElse-like behaviorfor our
Optionsemigroup, I'm inclined to not take this approach forXor.See also
#996 (comment)
cc @notxcain @aaronlevin @travisbrown @tpolecat @stew whom I think have all weighed in on this or similar items in the past