Update for #SwiftSettings

Author: gottesmm

proposals/0000-swift-settings.md

@@ -155,7 +155,7 @@ public struct SwiftSetting {
 }
 ```
 
-`#SwiftSettings` will expand to an empty string and is used only for syntactic
+`#SwiftSettings` will expand to an empty string and is used only for its syntax
 and documentation in the IDE.
 
 `SwiftSetting` is a resilient struct that cannot be constructed without a
@@ -211,6 +211,20 @@ restrictions, we expect that any feature that wants to be supported by
 and source stability impacts of adding support to `#SwiftSettings`. At minimum,
 the feature must obey the above requirements.
 
+Each argument can be passed to `#SwiftSettings` exactly once. Otherwise, an
+error will be emitted:
+
+```swift
+#SwiftSetting(
+  .defaultIsolation(MainActor.self),
+  .defaultIsolation(nil) // Error!
+)
+
+#SwiftSetting(
+  .defaultIsolation(MainActor.self) // Error!
+)
+```
+
 If a command line option is set to different values at the module and file
 level, the setting at the file level will take precedence.
 
@@ -244,7 +258,7 @@ extension SwiftSetting {
     public init() { fatalError("Cannot construct a DiagnosticGroup") }
   }
 
-  public static func warningsAsErrors(_ diagnosticGroup: DiagnosticGroup) -> SwiftSetting { ... }
+  public static func warningsAsErrors(_ diagnosticGroup: DiagnosticGroup...) -> SwiftSetting { SwiftSetting() }
 }
 ```
 
@@ -414,8 +428,29 @@ compiler settings since we are attempting to specifically support compiler
 settings that semantically can have file wide implications. If we wanted to
 support push/pop of compiler settings it would involve different trade-offs and
 restrictions on what settings would be able to be used since the restrictions
-would necessarily need to be greater.
+would necessarily need to be greater. As an example, we could never allow for 
+
+### Extending SwiftSetting to include parsing options
+
+We could make it so that parsing `#SwiftSetting` is done directly in the parser
+when we parse part of the macro grammar. This would work by evaluating the
+`#SwiftSetting` from its syntax and performing our pattern matching at parse
+time instead of at type checker time. We would then not create an AST for
+`#SwiftSetting`. This current proposal is compatible with the parsing approach
+since in such a case, `#SwiftSetting` would never show up at AST time.
+
+### Adding support for Strict Memory Safety
+
+We could also in the future add support to #SwiftSettings for Strict Memory
+Safety. This is not technically needed in the short term.
+
+### Adding the ability to opt out of module-level flags like warningsAsErrors
+
+We could add support for turning off features like warningsAsErrors at the file
+level. This would involve adding a new `disableWarningsAsErrors` method onto
+`SwiftSetting`.
 
 ## Acknowledgments
 
-TODO
+I would like to thank Holly Borla, Doug Gregor, Konrad Malawski and the rest of
+Swift Evolution for feedback on this proposal.