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

Using Raise via context parameter isn't (currently) as pleasant as via receivers unfortunately.

import arrow.core.raise.Raise
import arrow.core.raise.either

context(r: Raise<String>)
fun doSomething(): Unit = TODO()

context(r: Raise<Int>)
fun doSomething(): Unit = TODO()

fun main() {
  either<String, Unit> {
    either<Int, Unit> {
      doSomething() // Overload resolution ambiguity between candidates:
                    // context(r: Raise<String>) fun doSomething(): Unit
                    // context(r: Raise<Int>) fun doSomething(): Unit
    }
  }
}

whereas declaring with

fun Raise<String>.doSomething(): Unit = TODO()
fun Raise<Int>.doSomething(): Unit = TODO()

resolves correctly - but this doesn't work for cases where you already have a receiver, obviously. Even labelling the closest

either

with

intRaise@{

and wrapping with

context(this@intRaise) { doSomething() }

doesn't resolve it. Neither does attempting to use a contextual alternative

either

constructor:

inline fun <Error, A> either(block: context(Raise<Error>) () -> A): Either<Error, A> = arrow.core.raise.either(block)

Is there any specific reason why NonEmptySet and NonEmptyList have a custom toString representation rather than delegating to the underlying collection (and most likely using the standard

AbstractCollection.toString()

)?

I've had frequent very bad freezes with the Arrow plugin in a Maven project, I've had to disable it entirely. I've reported it on YouTrack and it seems it's something within IntelliJ itself, but could someone working on the plugin monitor this issue in case they communicate something to change?

This snippet vexes me in the collector collectI implementation:

val continued = when {
    collector.has(Characteristics.CONCURRENT, Characteristics.UNORDERED) ->
      started.parMapUnordered(concurrency) { collector.accumulate(accumulator, it) }
    collector.has(Characteristics.CONCURRENT) ->
      started.parMap(concurrency) { collector.accumulate(accumulator, it) }
    else -> started.map { collector.accumulate(accumulator, it) }

Specifically,

parMap

. From looking at its code, it seems that it's only ordered in the results that it produces (which are all

Unit

in this case), but the mapping itself happens in the same exact way as

parMapUnordered

. It thus seems unnecessarily expensive

Could we ever merge Ior and Either together so that

Left

and

Right

is valid for both? As in

Either <: Ior

,

Left <: Either

,

Right <: Either

,

Both <: Ior

Hey, I want to start contributing to Arrow. I have cloned and setup the project. Open source is quite new for me. Can someone please help me find beginner level issues to start with.