Hi Brent and Krystof, The proposal brought a lot of interesting discussions, but in the end, I think the right choice was made. It fits the Swift philosophy and rational, both in terms of the decision concerning the self. and concerning not having a warning. It took some time for me to try and adapt to not using self everywhere, but it is an interesting change.
David. > On 20 May 2016, at 00:00, Brent Royal-Gordon via swift-evolution > <swift-evolution@swift.org> wrote: > >> 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 > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
