would anyone like to help me by writing the sync laws?

I think that is because detekt finds all the generated classes in the second build

I just realised that there package

instances

in the

arrow-instances

module contains types related to the

arrow-data

. Should those be moved there?

no, the split is there because instances is a heavy package

and we acknowledge that some people don’t want typeclasses, just datatypes

specially those coming from funktionale

👍

@pablisco are we just able to just set the IDEA formatter to 4 spaces and apply that to the entire project?

Hmm, that's a good point, should be able to

yeah i think so

you should config the spaces in IntelliJ (

Editor > Code Style > Kotlin

) and then

Reformat Code

Cmd + Alt + L (Mac)

Today's question. I f I have a function. for instance:

fun <B> foldLeft(b: B, f: (B, A) -> B): B

Should the body be:

ev().fold({ b }, { f(b, it) })

or just

fold({ b }, { f(b, it) })

My understanding is that

ev()

is just a safe down cast , right?

It is. In this case the call to

ev()

is redundant.

that was my thought, I'll remove them then 😄

Unless we want the function on

WeakKind

right?

If you want to define

foldLeft

on

WeakKind

and

fold

is defined on

Weak

then you would need to downcast.

For instance,

Try

is doing this:

fun <A, B> Try<A>.foldLeft(b: B, f: (B, A) -> B): B = this.ev().fold({ b }, { f(b, it) })

I think that's what confused me

There

this.ev()

is also redundant I think.

We normally put extension functions in the Kind aliases to remove the burden of calling

ev()

for the library user

@christophsturm welcome!

the generated files should be made after the first build

strong suggestion, go to Settings -> Build -> Gradle -> Delegate to gradle wrapper

IntelliJ's can't handle how awesome we are

thanks!

While waiting for the Kotest project to release some changes, I'd like to be able to use those changes in my ongoing work to increase Arrow test coverage. How may I somehow replace Arrow's dependencies on Kotest with what's in Kotest's master branch? I've tried googling this, but get what seems like a lot of noise in the results. I figure folks on here must run into this situation with some frequency. Thanks!

What's the best way to benchmark a change in the Arrow codebase? Is kotlinx benchmark the way to go? I've restarted work on

value class Option

and I think it's ready for me to benchmark and present the results in a PR.

Just putting on your radar that I've made 2 separate PRs (#2950 and #2951) for a

value class Option

. From the benchmarks (included in the PRs), it seems as though there is marginal benefits of turning Option into a value class, but tangible benefits were seen when taking the more intrusive approach (in #2950) of optimizing nested Options. All the data and extensive commentary about upsides and downsides is available in the PRs. Perhaps my benchmarks are flawed as well, so if you have any suggestions for more representative benchmarks please let me know. All feedback is welcome!

@julian I was just using

parTupled

and it couldn't be resolved without providing

CoroutineContext

🤔 Did you encounter something like this while you were working on the PR?

This message was deleted.

When is the new Maintainer Commitée meeting time?