[swift-evolution] [Rejected] SE-0009 Require self for accessing instance members
tanadeau at gmail.com
Wed Jan 6 08:42:05 CST 2016
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*.
>> 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
>> * 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
>> * 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
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution