Stabilize EmptySerializersModule

[qwwdfsad]

Fixes #1765

[qwwdfsad]

See also #1765 (comment)

This is a legit concern that this decision is slightly out of line with our general design. We can discuss and decide whether we want to disrupt API a bit, deprecate EmptySerializersModule with replacement to EmptySerializersModule()

[olme04]

But why EmptySerializersModule() ? :) why not just SerializersModule() ?
From user perspective it looks reasonable to treat SerializersModule { } (so no configuration provided, what is possible now) and SerializersModule() the same.

[sandwwraith]

@olme04 It's like List(10) { i -> ... } constructor vs emptyList(). It clarifies the purpose. However, such logic hints that we should rename it to emptySerializersModule(), with small letter. WDYT, @qwwdfsad ?

[olme04]

then also SerializersModule {} should be renamed to buildSerializersModule { } as it's more like a buildList { } as there is already similar functions like serializersModuleOf already available like listOf :)
It's up to you to decide what code style is better here, but now all those builder functions have really different code styles

[qwwdfsad]

It seems like the most optimal way here is to be consistent within the library itself and name it EmptySerializersModule() like every other factory-that-looks-like-a-constructor in kotlinx.serialization and other kotlinx.* libraries.

The standard library is a different beast with different sets of tradeoffs. It still carries the heavy influence of Java since its earlier versions and tries to be consistent with itself, even though as time passes, we (Kotlin libraries developers) find better ways to design and express things. E.g. we could've decided that EmptyList() is the way to go, but changing emptyList at the current scale is just doesn't worth it

[sandwwraith]

If you want to make it multi-line, also split statements instead of using ;

If it's autoformatting, better to revert it

[qwwdfsad]

"Rename signature" for some reason apply formatting all over the place

[sandwwraith]

Probably we need to do one or two things:

• Optimize SerializersModule {} so it would return EmptySerializersModule when appropriate
• Make a diagnostic that suggest replacing SerializersModule {} with EmptySerializersModule() as we have with Json

[qwwdfsad]

I honestly do not see reasons to do so, this optimization doesn't carry any real value as well as the diagnostic.
Json is a different beast as it has a non-trivial initialization cost and also prevents any format-level caching.

[sandwwraith]

@qwwdfsad We already has the same problem with mapSerialDescriptor vs PrimitiveSerialDescriptor