[swift-evolution] [Rejected] SE-0009 Require self for accessing instance members

[Trent Nadeau]

You can probably use SwiftLint (https://github.com/realm/SwiftLint) and
create a new rule.

On Wed, Jan 6, 2016 at 9:17 AM, Honza Dvorsky via swift-evolution <
swift-evolution at swift.org> wrote:

> Hi all,
>
> since you mentioned:
> > 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.
>
> Are there any existing tools that already do that? I was hoping for a
> compiler flag where one could disable implicit self to keep the code more
> readable in out-of-Xcode scenarios, is there one? Or does the above just
> mean that it's "theoretically" possible to enforce it, even though there's
> no existing tool for it yet?
>
> I remember this being discussed in the conversation about this proposal
> and I haven't seen anyone being *against* there being a compiler flag,
> assuming it's off by default. To push that forwards, would we have to
> create a new proposal or could that be taken as an action coming out of
> this one (considering how many people still were *for* required self, even
> if we were in a minority)?
>
> Grateful for any advice, thanks.
> Honza Dvorsky
>
> On Wed, Jan 6, 2016 at 8:08 AM Douglas Gregor via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> The review of SE-0009 "Require self for accessing instance members`" ran
>> from December 16–20, 2015. The proposal has been *rejected*.
>>
>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md
>>
>> This proposal spawned a massive, polarized discussion with 200+ messages
>> involving 80+ participants. We’re thrilled at the enthusiasm and thank all
>> who participated. There were many, many interesting points made, along with
>> experience reports from various Swift code bases, ideas to help mitigate
>> the concerns that motivated the proposal, and so on. Quantitatively, the
>> overall community assessment of the proposal was roughly 5:2 against
>> requiring “self.”.
>>
>> The core team agreed that this proposal is not the right direction for
>> Swift. There are a number of reasons for this decision:
>>
>> * Mandatory “self.” introduces a significant amount of verbosity that
>> does not justify itself with added clarity. While it is true that mandatory
>> “self.” may prevent a class of bugs, the cost of eliminating those bugs is
>> fairly high in terms of visual clutter, which goes against the generally
>> uncluttered feel of Swift. Paul Cantrell put it well in his review
>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002910.html> when
>> he said, “anything that is widely repeated becomes invisible.” Swift
>> aims to avoid such boilerplate and repetition in its design, a principle
>> also espoused by the Swift API Design Guidelines
>> <https://swift.org/documentation/api-design-guidelines.html>.
>>
>> * The requirement to use “self.” within potentially-escaping closures is
>> a useful indicator of the potential for retain cycles that we don’t want to
>> lose. Additionally, developers can optionally use “self.” when they feel it
>> improves clarity (e.g., when similar operations are being performed on
>> several different instances, of which “self” is one).
>>
>> * The name-shadowing concerns behind the mandatory “self.” apply equally
>> well to anything found by unqualified name lookup, including names found in
>> the global scope. To call out members of types as requiring qualification
>> while global names do not (even when global names tend to be far more
>> numerous) feels inconsistent, but requiring qualification for everything
>> (e.g., “Swift.print”, “self.name”) exacerbates the problem of visual
>> clutter.
>>
>> * 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.”.
>>
>> Doug Gregor
>> Review Manager
>> _______________________________________________
>> 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
>
>


-- 
Trent Nadeau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160106/82cfb233/attachment.html>