Ryan Nett

I can see why they would want to start with just list-like collections, but I agree, I hope we get maps eventually too.

For exhaustiveness checking, I think a current hole would be classes like `Result` that have boolean methods for checking the type. Would the compiler be smart enough to handle this...

In case anyone mentioning JetBrains IDEs in here hasn't seen it yet: https://www.jetbrains.com/remote-development/

It would be nice to have this take the form of somewhat generic compression and archive abstractions so that libraries can be created as necessary for formats that don't receive...

@Mr3zee Assuming that all it would take is making the generated `callableMap` field public & adding it to the interface, I can do this in a PR if you like.

PR: https://github.com/Kotlin/kotlinx-rpc/pull/503. It's ready, just marked as draft due to https://github.com/Kotlin/kotlinx-rpc/pull/503#discussion_r2412275211

The inverse would also be nice, ideally with a customizable encoding (i.e. UTF-8, base64, hex, etc).

Another +1 for using streamlined delegation for this. It looks like Java is at least thinking about using the surrogate/delegate serializer approach ([ref](https://www.youtube.com/watch?v=guF2NvgJIN8)) for marshaling/unmarshaling. Their `SchemaRecord` seems like it...

Ah I see, so that decision should be based off of the descriptor the composite decoder was created with? It would be helpful to node this in the KDoc.

> In addition, if we follow every reference in the default value expression and hold it in the descriptor, it will potentially open a whole new class of memory leaks....