Ryan Nett

> Your approach will work in case there are simple references, but in cases like Foo(val a: String, val b: String = a + "x"), it won't. Ah yeah, good...

I had not, thanks. That would make implementing it yourself much more feasible but still IMO not something that should be required.

Here's another place a method like this would be useful: https://youtrack.jetbrains.com/issue/KTOR-8831/Performance-ByteWriteChannel.writeBuffersource-RawSource-could-be-improved It also implies that maybe it should be a be an extension on `RawSource`, not `Source`.

Ah yeah, I see the error now. Is this sort of restriction likely to stick around once these atomics & transforms are moved into the stdlib/compiler? Because it's rather restrictive...

I'd love to be able to filter by them, too. And especially to be able to set certain ones as hidden by default (i.e. for things like [@InternalSerializationApi](https://kotlinlang.org/api/kotlinx.serialization/kotlinx-serialization-core/kotlinx.serialization/-internal-serialization-api/)).

+1, especially Zstandard. While https://github.com/square/zstd-kmp exists, it doesn't support JS or WASM.

Hi there, this is specifically for non-KRPC servers. For example, a gRPC server being used by non-Kotlin clients, or any other cross-language RPC framework. It also came up in the...

My end goal is something like this: https://docs.spring.io/spring-ai/reference/1.1/api/mcp/mcp-annotations-server.html, where any Rpc methods annotated with `@McpTool` would be exposed as tools (I'm aware that annotations on methods aren't currently exposed). The...

You wouldn't, if you had an interface it would only be on the interface. My concern is more someone adding it on the server and not getting any feedback that...

That would be great, thanks. I'm assuming you'd include that `@RpcInfo` annotations would be accessible from the `RpcCallable` instances?