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

[Honza Dvorsky]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160106/e33f74a7/attachment.html>