Skip to content

Commit

Permalink
Expanded on API stability to include feature flag details
Browse files Browse the repository at this point in the history
  • Loading branch information
theoriginalbit committed Sep 18, 2024
1 parent 663dbcd commit ca9e756
Showing 1 changed file with 10 additions and 2 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -298,9 +298,17 @@ The initializer expression will never need to provide the allowed values paramet

This proposal creates new generated types and modifies the existing generated static functions for creating/accessing server definitions.

The change could be backwards compatible to any adopter that relies on default values provided by the static server functions.
#### New Feature Flag

Adopters that do not rely on the default values will have compile errors, though migration should be a straight-forward change as adopters were previously unable to provide _any_ value due to runtime validation; the generated enum cases should have a similar spelling to the previous string counterpart.
A feature flag, `serverVariablesAsEnums`, has been introduced to allow opt-in to the changes of this proposal.

When the feature flag is disabled the `RawStringTranslatedServerVariable` generator will be used for **all** variables, resulting in an identical output to the previous generator. However, when the feature flag is enabled the `GeneratedEnumTranslatedServerVariable` generator will be used for any variable that declares an enum field, and the `RawStringTranslatedServerVariable` generator will be used otherwise.

#### Compatibility

Given the previous generation, any adopter that relied on default values provided by the static server functions, e.g. `let url = try Servers.server1()`, will not experience any breaking changes by adopting the implementation from this proposal. The new generators will still provide valid default parameters, even for the generated Swift enums. Adopters that do not rely on the default values, however, will experience compile errors by adopting the changes in this proposal; though migration should be a straight-forward change as adopters were previously unable to provide _any_ value due to runtime validation, so the generated enum cases should have a similar spelling/shape to the previous string counterpart.

#### Other components

No API changes are required to other components, though once this proposal is adopted the runtime component _could_ remove the runtime validation of allowed values since the generated code guarantees the `rawValue` is in the document.

Expand Down

0 comments on commit ca9e756

Please sign in to comment.