I have created a proposal for making the self. optional warning. It can be viewed here:
https://github.com/charlieMonroe/swift-evolution/blob/master/proposals/xxxx-optional-warning-for-explicit-self.md Does anyone see a downside to this solution, having it an optional warning? > On May 20, 2016, at 8:36 AM, Goffredo Marocchi <pana...@gmail.com> wrote: > > Agreed, this is a topic that needs to be properly solved. > > Sent from my iPhone > >> On 20 May 2016, at 05:34, Krystof Vasa via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> From the rejection rationale: >> >>> * Individuals or teams that feel that explicit “self.” is beneficial for >>> their own code bases can enforce such a coding convention via tooling with >>> the status quo. If this proposal were accepted, those opposed to the >>> proposal would effectively have no recourse because the language itself >>> would be enforcing “self.”. >> >> With which I agree, giving the final decision to the user/team. This which >> pretty much means that teams and individuals such as myself will continue >> using the explicit self to keep on the safe side. However, the explicit self >> won't prevent you from the class of bugs refering to an instance >> variable/method by mistake unless there's a warning for not using the >> explicit self. >> >> Swift is designed (from what I understand) to become much more than just a >> language for "apps on the AppStore", i.e. something that could be used in >> medicine, military, etc. - in applications where code-safety is the number >> one priority since discovering bugs in production can have lethal >> consequences - and the current ambiguity of being able to refer to instance >> members without self is IMHO undermining Swift in this kind of usage. >> >> When you take a look at some of the more sensitive projects (in C/C++), they >> have most of the non-standard warnings turned on to prevent bugs at compile >> time - which is another aspect of Swift that is held up high, yet this is a >> place nasty bugs (in my experience) happen a lot (as per my original email >> here, I spent 2 hours debugging an app after refactoring a few larger >> methods into smaller ones) - and this is simply not acceptible e.g. for NASA >> usage (not saying NASA will be using Swift, just giving an example). >> >> Krystof >> >> >>>> On May 20, 2016, at 12:00 AM, 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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
