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
