I think it’s because the multiplatform support adds additional constraints beyond those already provided by the type system

But those constraints don’t add any more safety than would already be provided by the type system.

My multiplatform project precedes the multiplatform language features. For each platform, I compiled the cross-platform and platform-specific code as a single compilation unit, and the type checker caught any platform differences that affected my code.

But to meet the additional (and unnecessary) constraints imposed by the multiplatform language mechanisms, I have to write lots of boilerplate code and duplicate code in my platform-specific modules.

The huge increase in effort is not worth the benefit (slightly better navigation in IntelliJ)

If IntelliJ could work well with the same source directory being used by multiple modules, then multiplatform projects would require no new language features.

And much less work from the programmer

As soon as I do, I have to write

expect

declarations for all of the DOM APIs I use.

But I can’t because they are interfaces on JVM and external classes on JS

so I have to write my own

expect

types in the common module and identical

actual

implementations for JS and JVM platforms

And at that point it was obviously too much work for too little benefit.

The project is here: https://github.com/npryce/snodge

There is no code using the multiplatform language features.

only the original multiplatform code not using those language features exists

The main problem in that approach is that the same common code must be analyzed in multiple contexts, one at a time for each platform. Not only this is technically challenging, it's also unclear how to provide a reasonable IDE experience, when every bit of API you call is some quantum superposition of all available platforms.

But if that isn’t a good approach, could something be done to make the expect/actual mechanism more convenient -- require less boilerplate and duplicated code?

For example, in my code I don’t care if a platform type (W3C DOM types in my case) is provided by a class or an interface, because I only call methods, and don’t subclass or implement platform types.

If there was a way to

expect

a type without constraining its definition to be a class or interface, then I’d not have to write lots of wrapper types and boilerplate to forward to identical APIs on each platform — I could just use

actual typedef

.

I’d still have to declare all the

expect

types and

actual typedef

declarations, which is tedious, but maybe I could write an IDL generator for that.