@sam i’ve got a proposition for you. It’s about introducting continuation-passing style to the current arbitrary builder to improve its ergonomics and simplify how we might build, compose, and generate arbs. I’ve got a PR up for you to hopefully illustrate the proposed solution as well as the problem that solves. Hope you can take a bit of a peek when you’ve got the time https://github.com/kotest/kotest/issues/2493

I'm away atm but it looks interesting when I glanced. Will review properly later.

Seems like a really nice idea to me! Though I've no idea what would be involved from an implementation point-of-view

@sam what do you reckon in general?

Yeah we can merge it, I just want to understand it first, and I haven't had chance to look at it again

thinking

you could come up with a new name for it

what’s your recommendation @sam?

fun <T> fix(fn: suspend ArbitraryBuilderSyntax.(RandomSource) -> T): Arb<T>

not sure what the name should be

in kotlin std lib these types of builders usually come as a lowercase of its classname. so thinking out loud

fun <T> gen(fn: suspend GenBuilderSyntax.(RandomSource) -> T): Gen<T>

or in a different package

package io.kotest.property.arbitrary.builders

fun <T> arb(fn: suspend GenBuilderSyntax.(RandomSource) -> T): Arb<T>

I just realized we can also support

Exhaustive<T>.bind()

if you’re cool with it.

we had arb before and just removed it

yeah that’s my reluctance as well

and gen is a bit too generic, I think its better to come up with a name that indicates this builder is a bit funky

:lol:

what are some words that cover what we're doing, we're building, and extracting, its like a special do notation, a comprehensive of sorts

this solves a lot of our problem, we had like a very deeply nested data class that currently looking like callback hell because each of the fields have some sort of edge cases.

arbcomprehension

scouting arrow they name it under

.computation

package

bind

bind isn’t bad

our existing binds won't clash I don't think

checking

I think you're good because bind takes arbs + a fn

yeah they wont. in this case though, would you recommend

Arb.bind {
   val one = arbOne.bind()
   val two = arbTwo(one).bind()
   Foo(one, two)
}

or

bind {
   val one = arbOne.bind()
   val two = arbTwo(one).bind()
   Foo(one, two)
}

I personally like the latter

I think arrow did something similar thought, like

either {
   val a = myeither.either()
   val b = myeither2.either()
}

yeah they do that, they just put it under

arrow.core.computations.either

and

arrow.core.computations.option

either {
   val a = myeither.bind()
   val b = myeither2.bind()
   b
}

the nomenclature is also the same,

.bind()

so you don't like bind + bind

yeah it feels clunky, especially with kotlin stdlib and arrow have converged to doing

val flowValue: Flow<X> = flow {
  ...
}

val eitherValue: Either<L, R> = either {
  ...
}

val sequenceValue: Sequence<A> = sequence {
  ...
}

well they have generateSequence too

ah nice

I would say this kind of bind is advanced functionality, so you're only likely to use it if you know about it, and see it in the docs, so it doesn't matter hugely what it's called

i think i’m more inclined to do that now. i’m weighing the options

its not about adding the receiver but the fact you're restricting suspension

does that ever work?

arbitrary { delay(100) }

currently arbitrary isn’t inline

is arbitrary not marked as suspend

yeah that’s a new feature to be able to call suspend fun inside of the arbitrary builder.

yeah I assumed the function was already suspendable

😆 i wasn’t too keen to make breaking changes either

well sounds like we're set 🙂

thanks!

I think kotest property testing must be, or close to being, the most powerful out there now.

haha 100%!

not sure we need it then ?

hmm, not really a waste of time i don’t think. that suspend arb is actually quite cool

right

Mockk name the methods

coXYZ

, i don't like it but it's an idea, 🤔 another idea that i got is

suspendArbitrary