looking for additional feedback on the home page (attached screenshots). I've tried to give a bit more love to Resilience as @CLOVIS suggested, and make example projects more prominent as @dave08 suggested. Unfortunately I could not find a way to add more code, as @Javier suggested, without going into a super-deep change.

Hey! I'm having a look at the

accumulating

dsl, trying to clean things up and perhaps do a bit more reunification. Is there a reason why

Value

isn't a

value class

that uses

EmptyValue

or something under the hood? I'm guessing it's for simplicity or to prevent ABI explosion, is that right?

I seem to not be able to sync Gradle anymore in the Arrow repo because of an error:

Could not determine the dependencies of task ':arrow-annotations:check'.
> Could not create task ':arrow-annotations:animalsnifferMain'.
   > Could not create task of type 'AnimalSniffer'.
      > Could not generate a decorated class for type AnimalSniffer.
         > org/gradle/api/reporting/internal/TaskReportContainer

This seems to only happen with Gradle 8.11 which was committed yesterday. Not sure why this issue isn't happening in the repo though. This also happens when I try to do

./gradlew build

in the terminal. Can anyone confirm that this happens for them too? Edit: it seems that building triggers animalSniffer, and it seems that it highlights a bunch of errors?? Is animal sniffer just not used anymore? Is running

build

common practice?

What's the expected behaviour here?

either {
  accumulate {
    ensureOrAccumulate(false) { "hello" }
    this@either.raise("hi".nel())
  }
}

This results in

nonEmptyListOf("hi").left()

, but I can see an argument for it being

nonEmptyListOf("hi").left()

. It gets even more strange with early returns:

either {
  accumulate {
    ensureOrAccumulate(false) { "hello" }
    return@either 42
  }
}

Results in

Right(42)

, but the very similar:

either {
  accumulate {
    ensureOrAccumulate(false) { "hello" }
    42
  }
}

results in

nonEmptyListOf("hello").left()

Is this expected? Should the accumulated errors be raised instead?

Just sketching an idea here:

accumulate {
  val x by accumulating { ... }
  val y by accumulating { x }
}

Right now, if x fails, the second

accumulating

will fail too. I understand why this happens obv, but might we want something that makes

y

an

Error

if

x

fails? Is that even a useful idea? Are there any pitfalls I've missed?

with Arrow 2.x not being binary compatible with Arrow 1.x (specifically with the move of

ResourceScope

from

arrow.fx.coroutines.continuations

to

arrow.fx.coroutines

), SuspendApp-Ktor will need a release against 2.x. Is it even worthwhile to consider maintaining releases for both arrow1.x and 2.x simultaneously - especially given the potential option of maintaining both ktor2 and ktor3 variants.

saw the arrow 2.0.0 binaries are published so I've updated the ktor3/arrow2 PR for suspendapp

spending half a day in a bug... only to figure out it's actually a compiler bug https://youtrack.jetbrains.com/issue/KT-72084/Reflection-ISE-This-is-should-be-simple-type-for-inline-class-with-delegated-Java-interface

The repository https://github.com/arrow-kt/arrow-meta links to https://meta.arrow-kt.io/ which 404s

Does Raise really need an atomic for its completion status? Since it's only ever turned on, it seems unnecessary to have that be atomic.

The large api link here isn't working:

Also, wasn't there a link to the source code on each function in the api docs? It comes in handy quite a bit.

Couldn't these be inline too:

public fun <T> MutableState<T>.updateCopy(block: Copy<T>.() -> Unit) {
  update { it.copy(block) }
}

/**
 * Updates the value in this [MutableStateFlow]
 * by performing the operations in the [Copy] [block].
 */
public fun <T> MutableStateFlow<T>.updateCopy(block: Copy<T>.() -> Unit) {
  update { it.copy(block) }
}

the update functions themselves are and would allow to call suspend funs from within them... so if these were too, we could use the current ui state to call the suspend fun and update it atomically...

The Quiver link on the Arrow website is broken

hoi hoi! the weekend is coming, and open source is a good way to pass these cold days (if you are in the Northern Hemisphere, of course; in the Southern one please rather enjoy the sun). Anyway... after the release of Arrow 2.0 we're trying to expand our integrations with the community. We have recently added new Ktor modules (those will come in 2.1.0), because that was a common use case. We are actively looking for more of those! If you have any idea of use cases or integrations with other libraries we miss in Arrow or the surrounding ecosystem, please drop them in this thread 🧵

Why is

arrow.fx.coroutines.await.awaitAll

marked experimental but

arrow.fx.coroutines.await.AwaitAllScope

isn't?

Is there a tracking issue for the stabilization of

awaitAll

? I'm curious what's stopping it

regarding the Ktor integration, for the

putOrRaise

(and similar) helpers that take a payload parameter (implicitly receiving a la

fun <reified B: Any> Route.put(String, (B) -> Unit): Route

I'm hitting an overload ambiguity between the following:

inline fun <reified B : Any, reified R> Route.putOrRaise(
  path: String,
  crossinline body: suspend RaiseRoutingContext.(B) -> R,
): Route

and

public inline fun <reified R> Route.putOrRaise(
  path: String,
  crossinline body: suspend RaiseRoutingContext.() -> R,
): Route

when attempting to use the non-receiving form, i.e.

putOrRaise("/path") { "my result" }

. You could disambiguate either with

putOrRaise("/path") { -> "my result" }

or

putOrRaise<_>("/path") { "my result" }

but neither are intuitive or ergonomic to write. The only reasonable alternative I can think of is to rename the "receiving" helpers like

putOrRaiseReceiving

or

putReceivingOrRaise

or such, but again, not very ergonomic. Any other thoughts or ideas? Do we even need/want to include a "receiving" form of these, given a consumer could just use

put<B>("/path") { respondOrRaise { "my result " }

or

putOrRaise("/path") { val it = receiveOrRaise<T>() }

as needed?

Do you think Kotlin needs a dedicated meta-programming layer for macros and high-level compiler plugins, or are KSP and the current FIR compiler plugin APIs sufficient? https://github.com/arrow-kt/arrow-meta/pull/1083#issuecomment-2676189086

I've had a look a the suspendapp jvm shutdown bug and may have a fix (certainly warrants review) - is it best to push a PR against

arrow-kt/suspendapp

or

arrow-kt/arrow

given it's a fairly important fix i.e. would a

0.5.1

release be worth cutting from

arrow-kt/suspendapp

how is versioning of suspendapp going to follow from the merge into

arrow-kt/arrow

?

Is there a plan for migrating towards context-parameters (and targeting 2.1.20) in preparation for arrow 2.1? From testing it seems like consumers using context-receivers can still call context-parameters-compiled libraries

Pretty sure

@BuilderInference

is useless nowadays, although for some reason it hasn't been deprecated yet? Should we remove it to clean up the codebase a bit?

When taking in a

combine

function in Arrow, do we assume that such functions are associative?

With 2.1.20 out is it worth adding a module for context parameter bridge methods for simulating receivers to ease the transition?

Hey all, There is a request based on an original proposal by me to move kotlin-kafka away from my personal Github to an organisation. I would either need to create a new organisation solely for this project, or we can host it on the Arrow organisation. I'm unsure it belongs there, but others feel different. WDYT?

We should try thinking of a better description for the klibs.io description of Arrow-kt. https://klibs.io/project/arrow-kt/arrow. It's word for word our very old description

request for help ⚠️ We're having trouble publishing the Arrow 2.1.0 release because our workflow fails at "signing Android artifacts". I've written a PR to try to fix this problem, but it would be great if somebody with more experience on Android publication could have a look at it

Is there any value in adding

List<A>.asNonEmptyListUnsafe()

that avoids copying and simply wraps the list (potentially with a

require(isNotEmpty())

check? (same for NonEmptySet) - currently the suggested replacement for the old

Nel.fromListUnsafe

is

list.toNonEmptyListOrNull() ?: error(...)

however this currently iterates the list twice (effectively doing

iterator().let { listOf(it.next()) + Iterable { it }.toList() }

)

going back to the question raised a few days ago by @phldavies, I have a proposal for a new API that "wraps" an existing

List

(instead of copying it). Any feedback is welcome -> https://github.com/arrow-kt/arrow/pull/3611

I just missed the 2.1.1 release with my suspendapp-ktor PR laugh cry face palm