Inconsistent handling of enumerations

[jtdavis777]

While writing up a fix to #8311, I found an odd quirk of the language that I'd like to just bring up for discussion/clarification:

enum NonZero: ubyte {
  A = 1
}

table Data {
  one: NonZero = A;  // totally fine, expected behavior
  two: NonZero;  // flatc fails to generate with "error: default value of `0` for field `non_zero_default_enum` is not part of enum `NonZeroDefaultEnum`"
  three: [NonZero];  // totally fine, expected behavior
}

struct NonZeroStruct {
  arr: [NonZero:4];  // compiles???
}

This is currently shipping behavior, and receiving buffers with 0 as a value is not an issue, but I don't think we have a consistent or documented strategy for how to handle this case, especially across languages and generated object APIs.

[jtdavis777]

@bjornharrtell @mustiikhalil @aardappel @fliiiix (tagging all of you since you've been who I've been collaborating with most recently :D ) interested to hear your opinions on this and possibly add any context I'm missing.

[aardappel]

It's all doing the correct thing except for arrays, right? So we just need to make sure the error fires for arrays?

Generally it should error whereever the schema may cause the generated code to init default enums out of range. This may have been done inconsistenly because in languages like C++ it is expected you may have to deal with enums out of range when reading from possibly corrupt / different version files, but in other languages there's no provisions for this. So we should try to be strict I think.

[jtdavis777]

yes I think just arrays are the issue here. I maybe wrote more than I needed to :)