Tags on some non-struct types

[vassvik]

Certain types, in particular enums, could benefits from tags. For example: enums could provide more useful metadata for each entry, such as a pretty print name where you need non-identifier characters, whether it's a duplicate value, or signal some other intent.

Tonemapping_Mode :: enum {
	Clamp    `Clamp`,
	Linear   `Linear (Untouched)`,
	ACES     `ACES filmic`,
	Hable    `Hable`,
	Reinhard `Reinhard`,
	Hejl     `Hejl/Burgess-Dawson`,
}

[gingerBill]

There is one issue with enum tags from a syntax perspective:

Tonemapping_Mode :: enum {
	Clamp    `Clamp`,
	Linear = 1, // where does the tag go?
}

One solution could be to allow enum string as a type instead. The value itself would be an integer but it could be casted to a string with no problem

Tonemapping_Mode :: enum string {
	Clamp    = `Clamp`,
	Linear   = `Linear (Untouched)`,
	ACES     = `ACES filmic`,
	Hable    = `Hable`,
	Reinhard = `Reinhard`,
	Hejl     = `Hejl/Burgess-Dawson`,
}
assert(size_of(Tonemapping_Mode) == size_of(int));
x := Tonemapping_Mode.Clamp;
assert(string(x) == "Clamp");
assert(int(x) == 0);

[gingerBill]

One issue with this approach is that conversion of string -> enum would be slow, unless the enum's data was stored in a hash table of some kind. It would not be as quick as enum -> string (or int <--> enum).

[gingerBill]

And should enum string values be unique? Or if they are being stored as purely integers internally which represents the index of the string, does the uniqueness matter?

I would also make the name of the enum the default value.

[gingerBill]

One issue with the enum string approach is that the size of the backing integer is not modifiable because the syntax does not allow for it. That means that if you use this hypothetical enum string, it will always be size_of(int).