- a custom fixed enum defined as a subtype of
CompilerSetting(e.x.:StrictConcurrencyCompilerSetting)
I think this should say "nested type", since a "subtype" relation is something else.
- a custom enum defined as a subtype of
CompilerSettingthat the compiler synthesizes cases for depending on internal compiler data (e.x.: features forUpcomingFeatureCompilerSetting)
I would argue that since only a subset of experimental/upcoming features are meaningful to set on a per-file basis, perhaps this subset should be explicitly spelled out with case declarations?
- Other compiler flags whose impacts would necessitate exposing
compilerSettingsin textual modules. We view supportedcompilerSettingsas an anti-goal since appearing in the module header makes enablingcompilerSettingsaffect the way the module is interpreted by users, while we are designingcompilerSettingsto have an impact strictly local to the file. NOTE: This does not preclude compiler options that modify the way the code in the file is exposed in textual modules by modifying the code's representation in the textual module directly.
What about features like ExistentialAny or FullTypedThrows that change type checker behavior in inlinable code? It seems we'd either need special constructs to change compilerSettings in the middle of a swiftinterface (since the printed declarations can come from different source files), or we disallow such features from being set with compilerSettings.