Bevan Arps

Good idea. Added to our roadmap in #1192.

We believe flexible support has been delayed, and are trying to find out the new estimate.

Our `test` package already includes a fluent style API for doing assertions: ``` go test.AssertPackagesGenerateExpectedCode( t, finalState.definitions, test.DiffWithTypes(initialState.Definitions())) ``` We might add more options to allow removing specific functions and/or...

I strongly prefer keeping methods in the same file with the associated types - a legacy of having to play far too much mystery file exploration on prior projects, hunting...

_Can_ we move the ARM types into a subpackage? The API types need to reference the ARM types when they implement `CreateEmptyARMValue()` and related conversion routines. Is there anything on...

We are still interested in improvements here. @Porges suggested moving the _spec_ and _status_ types into separate subpackages, which would also allow us to simplify type naming.

From #1459: Consider performing the pluralization improvements step for spec and status of resources too. Add a golden test for pluralization?

Whether we still need to do this depends on the results of #1758.

Moving to `codegen-beta-0` milestone as we have a good-enough workaround for now (excluding the property); this may bite us later on though, so we still need to fix the issue.

We need to finish the adoption design and make this possible.