but essentially:

@Eugenio uploaded a file:

oh, I see

@Eugenio are we getting rid of the

extensions

utilities with your stuff that generates the extensions from the type class instances? If we forward all type class methods to the data type as extension functions with codegen we no longer need those

For type extensions

utilities.

how would that look in practice from a usage point of view?

(the implementation is beyond me to grok right now)

@raulraja right now I'm keeping them separate, so that the new system can be opt-in; we can deprecate them and remove them eventually

@jacob imagine you were to write, by hand, extension methods over the target of the type class, for every method that the type class declares, using specific instances for the implementation... Now imagine you didn't have to write them by hand 😁

That sounds nice 😀 so it does.away with the glue of the interfaces and the method definitions in favour of just method definitions?

@jacob no no, you provide the interfaces, and those are the "contract", that can also be defined in a library... then you provide the implementations (instances) and, if you annotate them, then extensions get generated in that package... so you can potentially have multiple implementations, and you import the one you want (as with any other extension)

JBs went ahead with the keep that introduces a Result type. Its intended use is exclusively for coroutines, so if you see people using it in libraries, flag it.

It’s very unfortunate thing that we have now construct with this “Never use it in your code”, I would like to see this as universal replacement for Try

honestly they should just generalise "union inline classes"

I need a review here

please

after confirming with @jrgonzalez this weekend, we’ve fixed the last blocker for 0.7.3

we’re going to start moving the machinery to release this or next week

if there’s anything you’d like to get into the cut, fix it ASAP

😄

Ok, I had another crazy idea during the weekend...

The biggest problem with

Kind

, in my opinion, is that classes have to extend it, so it can't be applied to existing classes (which is why there's all the parallel

ListK

,

SequenceK

, etc), right?

But what if

Kind

, behind the scenes, was erased at runtime and was actually

Any

? This way we could statically refer to any type at compile time as if it was

Kind

, and one wouldn't even need to call

fix

The problem, of course, is how to do that, and that's where the crazy part comes in...

You know how Kotlin uses this "magical" classes that don't really exist? Like

kotlin.List

,

kotlin.MutableList

, etc, these are called "builtins" and they are actually not hardcoded, since different platforms can have different versions of them (in fact they're shipped as metadata for runtime reflection)

(ping @pakoito @raulraja, you might enjoy this 😂)

That’s a lot of work, including some sort of compiler plugin

None the less, is an interesting idea