> On May 21, 2016, at 7:22 PM, Erica Sadun via swift-evolution
> <[email protected]> wrote:
>
>
>> On May 21, 2016, at 5:30 AM, Charlie Monroe via swift-evolution
>> <[email protected]> wrote:
>>
>> 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?
>
> 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.
-DW
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution