Casper

@ricardobarroslourenco I think you solved this one.

@jdemeyer this would be considered a bug, the namer work I started is not intended to be backwards incompatible, just standardize existing behavior which varies across languages by making it...

I no longer have the time to be an active maintainer anymore, sadly, but I agree its better to get some support rather than no support

Does the "Only generate one `.fbs` that includes all your other `.fbs` files" solution not work for your team? Flatbuffers is a volunteer-only project, I don't have the time in...

IMO, it would be better to just not support global "keep_naming" + opt out logic, since its such a niche use case... its not too hard for a minority of...

I have a slight preference for an attribute over a flag, but its not very strong. I'm mostly concerned with maintainability. A naive implementation would touch almost everywhere and be...

> I will deprecate the cpp-field-case-style and transition that over to a new field-case-style and object-case-style flags that can specify the intended output case. I think we still need to...

> My recommendation is to simply have a preserve-property-name flag. No need for that level of granularity. Any user can simply follow their own conventions, whether or not those conventions...

I think is a general flatbuffers problem -- it does not make sense for a FB struct to be self-referential since they don't support references and would be infinite size....

We do have these https://github.com/google/flatbuffers/blob/master/.github/workflows/build.yml