Inconsistency: "Blank serial names are prohibited"

[BenWoodworth]

Currently the @SerialName annotation allows blank names, but the serial descriptor constructors/builders do not

I noticed this when migrating an existing @Serializable @SerialName("") class from the auto-generated serializer to a custom one.

These throw:

• SerialDescriptor
• PrimitiveSerialDescriptor
• buildSerialDescriptor
• buildClassSerialDescriptor

But this does not:

@Serializable
@SerialName("")
data class MyClass(val a: String)

// {"":{a:"MyClass"}}
println(StringifiedNbt.encodeToString(MyClass("MyClass")))

I can see why maybe it should be disallowed all around, since e.g. class serial names are useful in error messages, but I thought I should post the issue to poke at what really should be allowed.

[BenWoodworth]

My use case has been for my NBT format implementation (knbt), and in NBT it's common for the top level object to have a blank name (example here). And using the class's serial name made sense for that... least it made sense when I first implemented it.

Now I'm wondering if it would be more appropriate to add something like an @NbtName annotation instead that should be used for this purpose. I really am not sure though. Some insight/pointers/opinions are certainly welcome :)

[pdvrieze]

@BenWoodworth You are 100% correct about the inconsistency. I'm not sure about allowing empty values for the serialname though as there are many formats that don't support it (including XML). If this is only for the top level you could pass the name in the function call, or as a policy for the top level name. Otherwise @NbtName may be the way to go.

Note that in any case the top level may need some special handling as in many "normal" cases you may want to use attribute names rather than type names (for example multiple string attributes should have different names).

[sandwwraith]

I think it makes sense to add diagnostic that would disallow @SerialName("") annotations, as I don't see much sense in blank serial names, except some rare cases like top-level NBT objects you mentioned

[BenWoodworth]

I don't have a strong opinion either way, so just food for thought, but as a default I usually prefer being permissiveness unless there's a good reason to add restrictions. I wouldn't be opposed to allowing any serial name

@pdvrieze

If this is only for the top level you could pass the name in the function call

Not a bad idea!

I'm not sure about allowing empty values for the serialname though as there are many formats that don't support it (including XML)

Same could probably be said about spaces and special characters, just something a dev needs to be conscious of when providing serial names. That does make me like the idea of format-specific serial names overrides like @NbtName though, kind of like @JvmName

@sandwwraith

I don't see much sense in blank serial names

This probably already thought of this, but empty JSON object keys also comes to mind. Though I agree, outside of dynamic maps/keys (for which @SerialName wouldn't even be used) that's pretty rare