Casper

> I feel like jumping to 3.0 signals to everyone that their are major changes, yet it just a small change to one language. Agreed, I can change the default...

Done - I just published it, but note that the fix for this issue didn't have to do with the cargo package, and also the cargo package is now at...

Hello, so this might be a little annoying to implement since every code generator is implemented slightly differently but #7142 might help. I will keep it in mind as I...

We don't centrally open files and give each code generator a file handle, code generators create files themselves decide on how the files are named individually. In some languages, file...

Also, imo, `case_fmt_.Type(x)` tells me more about the semantics of the generated code than `ToUpperCamelCase(x)`

> I would make overloads for each of the methods that take in a const std::string& as well. In the long run, it's not clear to me that we should...

That's a good point, and there's a similar shadowing issue in #6845. > Although whether this should be resolved by this proposal, by some other proposal, or just by better...

#7143 is another casing related bug: Two fields are different in the schema but, due to case-style normalization, generate the same symbol, which is invalid.

Looks like @tira-misu found - #7148 : Another example requiring context aware escaping, due to field-name/type-name collision, like @jkuszmaul's example above - #7149 : a reason to _not_ escape keyword...

@dbaileychess would you like to claim some subset of code generators to refactor? I don't mind doing it myself, but help is appreciated.