I'm using <binary-compatibility-validator> and kot...
# serialization
m
I'm using binary-compatibility-validator and kotlinx.serialization synthetic constructors show up in the API dump (the ones that take a
SerializationConstructorMarker
as last parameter). My understanding is that they're only used from the companion serializer. Would it be possible to hide them? Maybe make it internal? Or do they need to actually be public?
e
Doesn’t it make sense that it’s part of the API? If you remove the @Serializable, consumers will no longer be able to use your type with KxS out of the box. 🤔
m
I'm OK with Companion and serialiser being public. But the synthetic class constructor is an implementation detail IMO
a
are the constructors annotated with anything? For example,
@JvmSynthetic
? https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.jvm/-jvm-synthetic/ If they were, could BCV be set to ignore them?
m
Been thinking about that but I don't think BCV can ignore all synthetic symbols. If you take default arguments for an example, they're also using a synthetic method and this one is part of the binary API
a
yeah good point. It looks like the constructors are annotated with
@Deprecated
though. You could argue that all deprecated declarations should be excluded from the
.api
?
e
Deprecated methods are still necessary for compatibility. I think it’s dangerous to filter them
a
alternatively, you could a
doLast {}
in the Gradle tasks with some regex remove them from the
.api
files
anyway - these are workarounds. I think it’s a good feature request for KxS to add some sort of annotation marker, and for BCV to allow for more complex exclusions.
m
I'm thinking marking it internal in the Kotlin Metadata would work
BCV reads the metadata
a
do you have an example of what you want to exclude from the
.api
?
m
There's a lot more to this PR but it's basically this: https://github.com/apollographql/apollo-kotlin/pull/4702/files#r1117640434
Screenshot 2023-02-25 at 17.20.46.png