Yes, I will add a link to that proposal, although even that proposal doesn't seem to cover the full range of behavior of swift()
.
An unknown
-language-mode
argument must be an error, but an unknownlanguageMode()
argument could be a warning. For example:#if arch(x86) // ^~~ // warning: unknown architecture for build configuration 'arch' // note: did you mean 'i386'? #endif
Yes, it also occurred to me that sometimes packages need to be compiled with multiple versions of the compiler, so specifying languageMode(<7)
in a hypothetical Swift 7.0 compiler would generate an error in a Swift 6.x compiler.
I think it is desirable for the compiler to be strict within the range of language modes that it knows about. In the Swift 6.0 compiler that would be 4, 4.2, 5, 6.
So, any semantic version value between 4 and 6 that aren't a valid language mode should be an error.
All past language modes that are no longer supported are also known, so even there semantic versions less than 4 can be checked to ensure they are valid language modes.
For semantic versions beyond the highest language mode, the compiler could possible emit a warning, or possible accept it as is.
I would prefer to emit a warning, but that then runs afoul of people who prefer 'treat warnings as errors'.
Of course, since this functionality would likely be available in Swift 6.1 or later, this would not be an issue until a language mode beyond Swift 6 is introduced (which hopefully is a long while) and possibly the facility to suppress individual warnings will be added to the language by then.