define enums explicitly, particularly starting ordinal

[codefromthecrypt]

There are some enums that start negative, for example debug logging level is -1 and the rest start after that. other enums start at zero (ex errnosuccess in old wasi), others at 1. It would be nice to both have enum handling documented precisely, and also allow adjustment of the start ordinal similar to iota in go.

[codefromthecrypt]

playing with codegen, it seems zero, which makes sense, just that new wasi not starting with errnosuccess threw me off (as that was zero before).

In any case, I think it should be documented, and ideally flexible.

[sunfishcode]

At the Wit level, enum arms don't have specific integer values. Instead of specifying a specific concrete ABI, it Wit specifies a logical interface between two pieces of sofftware. The specific details about how they communicate, including the specific integer values used to represent an enum, aren't part of that logical interface.

The idea is that users of Wit interfaces should program to generated bindings, rather than to a specific ABI. That might mean that instead of writing code like "if (log_level < 0)", they'll write something like "if (log_level < LogLevel::Normal)", such that the source code doesn't have any hard-coded knowledge of the specific values of the log levels.

[codefromthecrypt]

I see, so what you are saying is that there is no compatibility promise given when writing specs in wit. For example, if I use wasi, which uses enums, I would have to use the same generator to ensure they match up. Correct?

[codefromthecrypt]

Do you know of a markup format that is possible to use as a concrete ABI, then? I misunderstood this one.

[codefromthecrypt]

FWIW meanwhile I will specify in two ways, %.wat imports and also wit.md until we can't do the latter. Actually, I think it should be well understood that this format shouldn't be used for concrete ABI because wasi using it makes it feel like it can be trusted.. eg something compiling against it a year afterwards ends up using the same signatures and flag/constant mappings. I would recommend wasi expressing some way to pin down the ABI to something concrete so that those needing compatible flags, enums and signatures can know what they are. Since it is early days for new wasi, there's perhaps time to figure out a solution for this.

[sunfishcode]

The component model here also defines a Canonical ABI, which (when finished) will be a stable concrete ABI for Wit interfaces. But, it doesn't have knobs to customize things like enum integer values, because end users will typically work with generated bindings rather than talking to the ABI directly.

[codefromthecrypt]

I would suggest to close this out by documenting/enforcing the start ordinal of enums in the canonical ABI as zero.

Imagine something like a clock enum. this sort of thing can't be left squishy as the guest/host must decide which are which and you can't require them to be using the same version of a generator.

make sense?

[Liamolucko]

The canonical ABI already implicitly defines the encoding of the first enum variant as zero, by encoding each enum variant as its index here:

component-model/design/mvp/CanonicalABI.md

Lines 716 to 735 in 5754989

	```python
	def store_variant(opts, v, ptr, cases):
	case_index, case_value = match_case(v, cases)
	disc_size = size(discriminant_type(cases))
	store_int(opts, case_index, ptr, disc_size)
	ptr += disc_size
	ptr = align_to(ptr, max_case_alignment(cases))
	c = cases[case_index]
	if c.t is not None:
	store(opts, case_value, c.t, ptr)
	def match_case(v, cases):
	assert(len(v.keys()) == 1)
	key = list(v.keys())[0]
	value = list(v.values())[0]
	for label in key.split('|'):
	case_index = find_case(label, cases)
	if case_index != -1:
	return (case_index, value)
	```

More specifically, the line store_int(opts, case_index, ptr, disc_size).

[codefromthecrypt]

cool, let's make it explicit, then? it is already a bit distracting that things are defined based on python and this seems a no brainer and little work to do.

[lukewagner]

Ok, filed #123.