[swift-evolution] Proposal SE-0009 Reconsideration

[Goffredo Marocchi]

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 at 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 at 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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution