[swift-evolution] Proposal SE-0009 Reconsideration

[Brent Royal-Gordon]

> What I don't understand is why can't this be an option. There are two camps, each advocating either preferences and each camp is quite vocal about it. Why not let the user decide? Hence my proposal to make it an optional warning.

> When you take a look at all the LLVM warnings options, there are things people usually don't have enabled, but advanced users or users who prefer safer code, can enable them. E.g. -Wfour-char-constants for warning about four-char OSTypes, etc. (just go through them in Xcode build settings).

Clang has lots of these kinds of warning flags, but so far, Swift does not. This is not an accident—it's a deliberate design. We don't want dragging a file between projects, or otherwise moving it from one context to another, to suddenly make it emit errors or warnings. There should not be dialects of Swift; there should be one Swift that everyone writes in.

However, that necessarily means that we can't provide a lot of configurability in terms of warnings. If every warning needs to be on for every file, then we need to choose warnings which have a high signal, and we need to have ways to disable them merely by editing code without changing its semantics (like by adding extra parentheses). This limits the kinds of warnings we can provide: we can't really warn about subjective style issues. Even the "unnecessary var" and "why don't you assign to _?" warnings are toeing the line of acceptable noisiness in Swift diagnostics.

So because of the philosophy behind Swift's error and warning design, we can't really support things like an "implicit self" warning. It quite simply runs counter to the language's goals. That's why we're interested in robust linting and formatting tools. Swift is packaged as a library not merely because it's a cleaner design, but also because it makes it easier to build accurate tools like these, things that can help fill in the gaps in Swift's own tooling.

-- 
Brent Royal-Gordon
Architechies