yes, but still

Either.catch

needs to be suspend

agreed

ok, let’s see what people say with those deprecations xD

the one in ApplicativeError isn’t

so it won’t delegate

the one in ApplicativeError should not be there

or it should be suspend as well

anything that throws is an effect

do we want to mix effects with lower parts of the typeclass hierarchy?

well, monad does it already

yeah, it’s the same deal, some algebras may have effectual combinators but not necessarily know how to run or manage them. For example suspended bind

Updated the PR with suspend constructors

We’ll tackle ApplicativeError#catch in another PR

Approved

👋 hello! 😃

I think the problem there is how are you declaring the dependency

that error appears when the compiler miss the class because it's not available on runtime or compile time

I added this to the gradle deps:

compile project(':arrow-core-data')

try with

implementation

It’s related to

@extension

and

@higherkind

being in the same module

Or 2 code generators that reference each others code which is not possible hence

NonExistentClass

Resolved 🙂

Awesome!

The latest merge to master changing the Kotlin version did not produce the snapshot because it failed to build due to what it looks like a change on behavior in Regex in the new version of Kotlin. This ank kdoc snippet: https://github.com/arrow-kt/arrow/blob/62f692397ef44e6acde12af817d94a19d2ce9621/modules/core/arrow-core-data/src/main/kotlin/arrow/typeclasses/Functor.kt#L49 is incorrectly processed here https://github.com/arrow-kt/arrow/blob/557b8c06d46d63145f43101cca0b4427bb9bd26e/modules/ank/arrow-ank/src/main/kotlin/arrow/ank/interpreter.kt#L219-L240 resulting in: https://app.bitrise.io/build/c302b0457b8867cd#?tab=log

fun main(args: Array<String>) {
  val result =
  //sampleStart
2 }
  //sampleEnd
  println(result)
 }

So the bump to 1.3.31 broke master. Let’s merge @Imran/Malic’s PR and then just bump the version down again

if anyone wants to experiment with removing that additional flag just in case that’s why it broke, they can do it locally

For these sort of PRs, do we apply any strategy for deprecation?

Some random people approached to me lately "complaining" (mostly giving productive feedback) about some changes that supposedly were breaking and broke their builds on upgrade, such that we didn't use proper deprecation strategies. To be honest I've not put any time or effort on double checking those concrete issues, but I believe we're being careful with using proper deprecation strategies overall, aren't we? Mostly the closer we get to stables

we try to deprecate most of the time but in this case it’s 0.10.0 because there is a lot of breaking changes