Could anyone talk about the current state of the two "type-class"-like KEEP-proposals? (https://github.com/Kotlin/KEEP/pull/176 and https://github.com/Kotlin/KEEP/pull/87) What is their current status? Is there any indication that one of them will be implemented into the language in the "not-so-distant" future?

Regarding type classes as far as KEEP-87 is concerned is being reworked in a much more flexible system that allows encoding of type classes, type refinements, union types etc. We are working on it on Arrow Meta and it's called Type Proofs. We plan on resubmitting keeps for all these features after April as we test them in the arrow code base.

union types as in

fun foo(x: String | Int) = when(x) {
  is String -> {...}
  is Int ->  {...}
}

? that sound's awesome!

Type classes as in proyecting members from one type to another as syntax https://github.com/arrow-kt/arrow-meta/blob/sv-test-proofs/prelude/src/main/kotlin/arrow/typeclasses.kt

that looks incredibly promising! You guys are doing god's work over at arrow! could you explain the

Syntax<A>

part? what does that

Syntax

interface do / mean?

It may auto generated but essentially type classes have two kinds of members

I'll need to wrap my head around most of that, haha! sounds brilliant! How much of that can you imagine ever being implemented into standard kotlin? I feel like It's realistic to have Unions some day, and the whole KEEP-87 idea seems to be pretty universally liked as well, but I cannot really imagine having anything resembling dependent types or type-based Proofs in Kotlin.. but maybe that's just me ;D

I'm not sure but the good news is that plugins are already powerful enough to do these things and the output they produce is compatible in regular Kotlin

so the compiler check's the String-literal in

TwitterHandle("@adminxxxxxxxxxxxxxxxxxxxxxxxx")

, check's it with the validate function and then knows it's not a valid TwitterHandle, thus the code does not compile? That sounds pretty cool! But how does this work with non-literal values? I see you have these examples:

val runtimeAdminWillBeNull: TwitterHandle? = admin 
//null

val runtimeWhateverIsValidated: TwitterHandle? = whatever 
//TwitterHandle("@whatever")

.. Am I correct in understanding it the following way: if you provide a literal, the compiler can know that your value is either valid or not, and validate the type at compile-time. If you give it a value or otherwise a "calculation", It cannot compile-time verify and thus returns a nullable type?

Yes, thou it can be the full validation map,.either or other type beside nullable

So this is a kind of implicit conversion, specialized for type-refinement? you provide the

@Proof

function that converts from

String -> TwitterHandle?

(or one that converts into

Maybe<TwitterHandle>

, etc) which is then used to generate the inline class instance? what would happen if i did

TwitterHandle(admin)

(put a non-literal value into the constructor)?

It fails to compile and forces you to use instead

TwitterHandle.from

or one of the validation methods in the refined interface, still under design

that makes sense, i guess ;D I'll look be looking forward to try that stuff out! Thanks for your time, man ;D

No problem, any time! 🙂