[swift-evolution] Proposal SE-0009 Reconsideration
david at alkaline-solutions.com
Sat May 21 20:49:16 CDT 2016
> On May 21, 2016, at 7:22 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
>> On May 21, 2016, at 5:30 AM, Charlie Monroe via swift-evolution <swift-evolution at swift.org> wrote:
>> I have created a proposal for making the self. optional warning. It can be viewed here:
>> Does anyone see a downside to this solution, having it an optional warning?
> I suspect the only issue is that there are lots of things that people would want to have as optional warnings, and it might be hard to justify why this optional warning is more important than other optional warnings all of which would benefit the user. In previous conversations, I believe "can it be linted?" has been proposed as the question to be asked for this kind of thing.
> I haven't paid attention very closely to most of these conversations and I did vote against an explicit self requirement.
> -- E
I believe the Swift team has taken a stance that there should be no optional warnings. Notice the absence of any optional warning flags today reported by the swift compiler.
The warnings have to meet a suitably high bar such that the code changes to disable the warning make the code clearer. For an example, @warn_unusued_result functions give a warning unless you assign to underscore, e.g.
_ = list.sort()
On the other hand, “require every reference to be fully qualified” sounds more like something to add to a project like SwiftLint. I subjectively state that littering my methods with redundant “self” references makes the logic of my code harder to digest.
This is why I was suggesting earlier in this thread to focus on warnings when variables and methods are being shadowed, and now to declare in code that a name is meant to shadow another name. I suspect that (with sufficient bikeshedding) this would meet the bar for the swift always-on warnings.
More information about the swift-evolution