I’m seeing Kotlin’s binary compatibility tool reporting `ComposableSingletons` classes being generat...

# compose

[Zach Klippenstein (he/him) [MOD]]

I’m seeing Kotlin’s binary compatibility tool reporting ComposableSingletons classes being generated and exposed as public. It seems like it might be some sort of a lambda cache, which seems fine, but does it need to be public? It’s not clear where it’s coming from, and I’m nervous about what this means for future binary compatibility because it seems to have appeared after adding a private @Preview function which I wouldn’t expect to have public API implications.

I don’t see anything about this in the bug tracker, and I’m not sure it’s a bug anyway. Some references to this type in stack traces in this thread, but nothing specifically about whether it should be public API either.

[Adam Powell]

cc @Leland Richardson [G]

[shikasd]

I think they were public because they are used to substitute default lambda parameters in the callsite (which could be in another module)

Not sure if that's still the case though

[Zach Klippenstein (he/him) [MOD]]

We’re talking all private or internal code here though, nothing accessible from other modules.

[shikasd]

Ah, nvm, I am completely wrong, they should only be used internally in the file, so could easily be private

[Arkadii Ivanov]

I remember you raised this issue, isn't it the same? https://github.com/Kotlin/binary-compatibility-validator/issues/54

[Zach Klippenstein (he/him) [MOD]]

I don’t think so. All our internal and private stuff is staying out of the api dump, it is specifically this one class that Compose is generating that’s getting included