New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ApplicativeError constructors from the Core types #988

merged 7 commits into from Oct 28, 2018


None yet
3 participants

pakoito commented Aug 15, 2018

No description provided.

@pakoito pakoito requested review from raulraja, JorgeCastilloPrz, nomisRev and arrow-kt/maintainers Aug 15, 2018

pakoito added some commits Aug 15, 2018


This comment has been minimized.

codecov bot commented Aug 15, 2018

Codecov Report

Merging #988 into master will decrease coverage by <.01%.
The diff coverage is 60%.

Impacted file tree graph

@@             Coverage Diff             @@
##             master    #988      +/-   ##
- Coverage     42.61%   42.6%   -0.01%     
  Complexity      746     746              
  Files           359     359              
  Lines          9865    9867       +2     
  Branches       1078    1078              
  Hits           4204    4204              
- Misses         5345    5347       +2     
  Partials        316     316
Impacted Files Coverage Δ Complexity Δ
...ain/kotlin/arrow/test/laws/ApplicativeErrorLaws.kt 100% <100%> (ø) 9 <0> (ø) ⬇️
.../main/kotlin/arrow/typeclasses/ApplicativeError.kt 75% <33.33%> (-15%) 0 <0> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7780050...56c4991. Read the comment docs.

@@ -15,6 +12,15 @@ interface ApplicativeError<F, E> : Applicative<F> {
fun <A> E.raiseError(dummy: Unit = Unit): Kind<F, A> =
fun <A> OptionOf<A>.lift(f: () -> E): Kind<F, A> =

This comment has been minimized.


raulraja Aug 15, 2018


These should not be called lift but instead asRaisedError or something similar that is inline with the idioms used by the interface to actually place errors in the context.
I'm also not a fun of having these functions in the interface because we are automatically exporting the extension functions for the data types in Arrow 0.8.0 and these are special cases where the type class provides convenience functions for data types that it implements. I understand though why you place them here in order to avoid the constrain in the type classes if they lived elsewhere. We are gonna have to also find a way to flag these as non exportable for syntax on the data type as they go out of the conventions.

pakoito added some commits Aug 19, 2018

Merge remote-tracking branch 'origin/master' into paco-monaderrorfrom…

# Conflicts:
#	modules/core/arrow-typeclasses/src/main/kotlin/arrow/typeclasses/ApplicativeError.kt
#	modules/docs/arrow-docs/docs/docs/typeclasses/applicativeerror/

@pakoito pakoito merged commit a48e824 into master Oct 28, 2018

4 checks passed

codecov/patch 60% of diff hit (target 42.61%)
codecov/project Absolute coverage decreased by -<.01% but relative coverage increased by +17.38% compared to 7780050
continuous-integration/travis-ci/pr The Travis CI build passed
continuous-integration/travis-ci/push The Travis CI build passed

@pakoito pakoito deleted the paco-monaderrorfromcore branch Oct 28, 2018

@raulraja raulraja referenced this pull request Nov 2, 2018


Release 0.8.0 #1080

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment