Consider adding native targets support

[rafaeltonholo]

Hi there,

Thanks for all your work on KotlinPoet! I'm currently developing a project that generates Kotlin code, and KotlinPoet looks like a great fit for improving our code generation process. However, my use case includes native targets (mac, linux, windows), which I see are not yet supported.

I wanted to reach out to understand whether native support is on the long-term roadmap or if there are any near-future plans to explore it. I realize this might not be a high priority right now, so I’m mainly trying to gauge whether it's even on your radar.

I've done a bit of research and noticed that supporting native targets may involve changes like implementing String.codePointAt(index: Int): CodePoint and some other external functions. I'm aware there could be additional complexities and would love to learn more about potential blockers.

If there's any interest in moving toward native support, I'd be happy to help, though I might need guidance from those more familiar with the project's architecture.

Thanks again for your hard work on this library, I really appreciate it and look forward to hearing your thoughts.

[JakeWharton]

Multiplatform support is tracked by #304. As you can see, some PRs have been merged in the past. There's no technical blockers, just annoyances with the language which make things overly verbose.

[Egorand]

Thanks for the offer to help out! @ForteScarlet - any areas where you think you'd need an extra set of hands?

[ForteScarlet]

@Egorand Hello! Personally, I feel that there are currently two impediments to migrating to KMP, one being what is described in #2040 (comment) (and also #304 (comment)): attitudes towards JVM types left over from past versions. (However, most of them are tagged with DelicateKotlinPoetApi and have not been removed so far.)

The other is the issue of differences between multiple platforms (e.g. CodePoint, numeric types, regex (KT-71003), etc.) as stated in @rafaeltonholo.

The rest is just pure code migration workload, the amount of which depends on the amount of expect/actual content. (I know little about native platforms, and I'm not sure we'll find any other issues. 😔)

Speaking of which, regarding #2040 (comment), what is the final acceptable solution for us 🤔? It would probably be a bit more work if we don't accept JVM platform type compatibility via typealias at all and have to use expect/actual types instead.

But also, as @JakeWharton said, using typealias adds quite a few extra types to the common that can only be used by the JVM. But do we need to keep the use of javax.lang.model for generating Kotlin code?