Could be arrow meta also used to resolve instance ...

# arrow-meta

[dcampogiani]

Could be arrow meta also used to resolve instance of Kotlinx.Serialization (some context in comments) at compile time?

[dcampogiani]

To pass from a given T to its String representation you could use this method

[dcampogiani]

https://github.com/Kotlin/kotlinx.serialization/blob/master/runtime/commonMain/src/kotlinx/serialization/json/Json.kt#L93

[dcampogiani]

You have to pass both, the instance T and a Serializer for that given T

[dcampogiani]

If you don’t want to always pass the serializer you could use

[dcampogiani]

KClass<T>.serializer

[dcampogiani]

but that won’t always work
https://github.com/Kotlin/kotlinx.serialization/blob/master/runtime/commonMain/src/kotlinx/serialization/PlatformUtils.kt#L16

[dcampogiani]

and is not recommended

[dcampogiani]

https://github.com/Kotlin/kotlinx.serialization/blob/master/runtime/commonMain/src/kotlinx/serialization/SerialImplicits.kt#L16

[simon.vergauwen]

It's possible with a higher abstraction such as @Proof that @raulraja already build and showed in several talks.

Since all you want to do is proof that those implementations exist, and rely on it.

[simon.vergauwen]

The passing technique they're using in KotlinX Serialisation is exactly the same as passing around typeclass instances as we currently do in Arrow.

So both can solved in the same way.
A concrete compiler plugin (similar to kapt for Moshi), typeclasses, proofs, ..

[dcampogiani]

🙏

[dcampogiani]

It this way I’ll have both simpler APIs and compile time safety, right?

[simon.vergauwen]

Yes, it would allow you to define 1 serializer per type and it would result in a compilation error if there is ambiguity or an implementation missing.

[dcampogiani]

Thanks