How can find the description for switches?

[xTachyon]

I'm trying to generate the protocol based on the specifications on this repo, but I can't tell where I should be looking to understand what's the description for switches cases.

Taking the boss_bar packet as an example, how can I tell the variants names like here (add, remove, update health, etc.)?

Right now what I managed to generate is:

pub enum BossBarResponse_Enum<'p> {
    Variant_0 { title: &'p str, health: f32, color: i32, dividers: i32, flags: u8 },
    Variant_2 { health: f32 },
    Variant_3 { title: &'p str },
    Variant_4 { color: i32, dividers: i32 },
    Variant_5 { flags: u8 },
}

Which is quite unhelpful for whomever tries to use the packet. I don't see how I could generate this better. Also I don't see how I can figure out that 1: remove is even a valid choice for this packet.

Thanks.

[rom1504]

Some history on this at #135

See also this https://github.com/PrismarineJS/minecraft-data/pull/163/files

I think the best solution is to have English comments for every field and extract that from wiki.vg initially

We discussed that several times over years (and even merged one version) but it's not quite done.

As to why I think that's the best solution: Mojang protocol is quite convoluted, English is probably the only reasonable solution to explain what is going on in some packets (rather than some sophisticated metadata)

[rom1504]

Another solution is you introduce another library like mineflayer that handles abstracting away the packets so that most users never interact with them.

[xTachyon]

I'm sorry, I don't quite understand how I'm supposed to use this.
The comments idea seems to be documentation for the fields, which is fine, but there's no one word that can describe the action in code.
I also don't see how can I tell that variants without fields are even correct for the type (for the original example, 1), because they don't appear at all.

[rom1504]

Yeah switch are not union types

There are several possible solutions going from low investment to high investment

1. You handle like in js eg no verification in low level code, only high level code encodes this information
2. You have another json file to store this kind of union types information and then use it
3. You improve protodef types to include such information