Feature Considerations for v.Next generators

• handle suffixes like “operations”/“models” consistently across languages and in general (see #1491)
• consistently handle LRO intial, progress and final responses, like progress reporting or error handling (see #1418, #960, #1128, #1441, #2295)
• consider model flattening combined with polymorphism and multiple hierarchies (see #1409)
• handle optional body parameters consistently (see #1629)
• handle markdown documentation (see #1640, #1562)
• support timeouts and other things (see #1462; maybe the layered HttpClient approach, see proposed Storage SDK architecture; see #1651, #1445)
• pluggable support of other media types (and probably native support of stuff like text/plain; see #1527; also check out https://github.com/Azure/autorest/issues/2650)
• better error treatment. Make error types modelable and put server response (message, etc.) into thrown exception (see #2022, #2496, #1024, #1111, #855, #1523, #2341, https://github.com/Azure/autorest/pull/1654)
• decoupling HL and LL code gen (implicit return values #787; abstract base classes #995; multi-verb madness and required/readOnly; auto-properties like fresh UUIDs; HL models with Equals/GetHashCode/… #1251; use external models for HL #1752; unsigned types #2422)
• less data duplication during (de-)serialization (see #684)
• better enums (non-string, see #833; extensible enum class/string, see #733; multi-select enums, see #1867; single value enums w/o const, see #1449)
• object initializer list instead of fixed constructors (see #747, #977 🎉)
• fix accessibility of some service client constructor (see #907)
• modularity, pluggability (see #1021)
• revise streaming (see #673, #903)
• make models round trippable (deser. + ser = equivalent information) by default, i.e. add an additional properties bag unless additionalProperties is explicitly disabled
• ensure that POSTs can have empty json ie, {} bodies instead of sending an empty HTTP body. (#2330)
• support configurable output formatting (tabs, charset, linefeeds)
• forward documentation (operation groups #289; enums #1786)
• deprecated/obsolete on everything (see #1285) 🎉 (C#)
• allow specifying existing types to substitute for generated ones. (#2472)
• better default: non-primitive (see https://github.com/Azure/autorest/issues/1833#issuecomment-286591990), actually don’t just send it over the wire (see #1607)
• do the right thing regarding validation (https://github.com/Azure/autorest/issues/1607#issuecomment-260443923)
• HL/convenience concerns:
  • return specific value depending on status code (i.e. even if actual response is empty) - careful, this is not about the wire, so think about appropriate representation
  • trivial transformations like a returned property of oneOf: number/string/boolean to string (if it is decided that one would rather deal with string than having to deal with… object? some complex type that encapsulates the oneOf?)
• consider allowing same property name to occur multiple times across inheritance chain (perfectly valid Swagger, but one has to consider the implications on code generation – in C#, one could override, but what if the subclasses type is more narrow than the base one? use new?)

[asvishnyakov]

@fearthecowboy @olydis Is there any progress about #609 (Generated C# code should be decorated with GeneratedCodeAttribute attribute)? It’s very useful: for example, it tells analyzers to exclude AutoRest-generated code from analyze process.

[begoldsm]

@fearthecowboy nice! Part of the “standard operation class names” for node should include this issue: https://github.com/Azure/azure-sdk-for-node/issues/2193