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


(Douglas Gregor) #1

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


(Honza Dvorsky) #2

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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Greg Parker) #3

We don't want language-changing compiler flags. swiftc doesn't even have flags to control warnings today, though I don't know if we'll be able to preserve that forever.

Style rules should be enforced by tools other than the compiler.

···

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

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.

--
Greg Parker gparker@apple.com Runtime Wrangler


(Trent Nadeau) #4

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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau


(Douglas Gregor) #5

I tend to agree with Greg, in part because I don’t like the idea of having a cornucopia of potentially-conflicting warning flags for different coding conventions within the compiler proper (e.g., -Wimplicit-self vs. -Wunnecessarily-qualified-self, for the opposite ends of the spectrum in this particular debate).

The core team did talk about such a warning flag briefly, and there was no consensus either way. We think this needs more discussion in the community, but not as a discussion specific to requiring “self.”. Rather, the question is “does checking of coding conventions belong in the Swift compiler or in a separate tool?” and “how do we decide which coding conventions are important/popular/useful enough to include?”

  - Doug

···

On Jan 6, 2016, at 6:56 AM, Greg Parker via swift-evolution <swift-evolution@swift.org> wrote:

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

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.

We don't want language-changing compiler flags. swiftc doesn't even have flags to control warnings today, though I don't know if we'll be able to preserve that forever.

Style rules should be enforced by tools other than the compiler.


(Matthew Johnson) #6

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.

We don't want language-changing compiler flags. swiftc doesn't even have flags to control warnings today, though I don't know if we'll be able to preserve that forever.

Style rules should be enforced by tools other than the compiler.

I tend to agree with Greg, in part because I don’t like the idea of having a cornucopia of potentially-conflicting warning flags for different coding conventions within the compiler proper (e.g., -Wimplicit-self vs. -Wunnecessarily-qualified-self, for the opposite ends of the spectrum in this particular debate).

The core team did talk about such a warning flag briefly, and there was no consensus either way. We think this needs more discussion in the community, but not as a discussion specific to requiring “self.”. Rather, the question is “does checking of coding conventions belong in the Swift compiler or in a separate tool?” and “how do we decide which coding conventions are important/popular/useful enough to include?”

I agree that this is an important discussion to have.

A possible middle ground might be an external tool that is also available during compilation with a single -Wstyle-violation warning. The “style definition” for a module would need to be specified somewhere available to both. This would definitely be preferable to a long list of style-specific warning flags IMO and would allow different teams to adopt different workflows.

Matthew

···

On Jan 6, 2016, at 11:47 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 6, 2016, at 6:56 AM, Greg Parker via swift-evolution <swift-evolution@swift.org> wrote:

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

  - Doug

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Charles Srstka) #7

I just spent a half hour last night debugging an issue that turned out to be caused by something getting written to a property which I thought was being written to a local variable, due to implicit self.

Clang had compiler flags to enforce specific stylistic rules, such as -Wobjc-missing-property-synthesis for those who disliked the auto-synthesis feature (and I never even understood that particular objection). It seems to me that this compiler warning would be at least as acceptable as that.

Charles

···

On Jan 6, 2016, at 8:56 AM, Greg Parker via swift-evolution <swift-evolution@swift.org> wrote:

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

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.

We don't want language-changing compiler flags. swiftc doesn't even have flags to control warnings today, though I don't know if we'll be able to preserve that forever.

Style rules should be enforced by tools other than the compiler.


(TJ Usiyan) #8

One point to make is that requiring self is *not* the only fix for that
problem. You could also avoid shadowing. Which choice you make is up to you.
TJ

···

On Wed, Jan 6, 2016 at 2:18 PM, Charles Srstka via swift-evolution < swift-evolution@swift.org> wrote:

I just spent a half hour last night debugging an issue that turned out to
be caused by something getting written to a property which I thought was
being written to a local variable, due to implicit self.


(Honza Dvorsky) #9

Thanks Trent, I created an issue an there seems to be will to add it as an
opt-in rule: https://github.com/realm/SwiftLint/issues/321

Greg and Doug, thanks for the details, I didn't realize that there aren't
any language flags yet. In that case, I agree that moving this
responsibility to a tool higher up the chain makes sense. And hopefully
having to install a linter won't be an issue for developers going forward.

···

On Wed, Jan 6, 2016 at 6:47 PM Douglas Gregor <dgregor@apple.com> wrote:

> On Jan 6, 2016, at 6:56 AM, Greg Parker via swift-evolution < > swift-evolution@swift.org> wrote:
>
>
>> On Jan 6, 2016, at 6:17 AM, Honza Dvorsky via swift-evolution < > swift-evolution@swift.org> wrote:
>>
>> 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.
>
> We don't want language-changing compiler flags. swiftc doesn't even have
flags to control warnings today, though I don't know if we'll be able to
preserve that forever.
>
> Style rules should be enforced by tools other than the compiler.

I tend to agree with Greg, in part because I don’t like the idea of having
a cornucopia of potentially-conflicting warning flags for different coding
conventions within the compiler proper (e.g., -Wimplicit-self vs.
-Wunnecessarily-qualified-self, for the opposite ends of the spectrum in
this particular debate).

The core team did talk about such a warning flag briefly, and there was no
consensus either way. We think this needs more discussion in the community,
but not as a discussion specific to requiring “self.”. Rather, the question
is “does checking of coding conventions belong in the Swift compiler or in
a separate tool?” and “how do we decide which coding conventions are
important/popular/useful enough to include?”

        - Doug


(Charles Srstka) #10

Avoiding shadowing (or avoiding anything else for that matter) is also possible to flub accidentally. There’s no optional warning about shadowing either, AFAICT.

Charles

···

On Jan 6, 2016, at 1:34 PM, T.J. Usiyan <griotspeak@gmail.com> wrote:

On Wed, Jan 6, 2016 at 2:18 PM, Charles Srstka via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I just spent a half hour last night debugging an issue that turned out to be caused by something getting written to a property which I thought was being written to a local variable, due to implicit self.

One point to make is that requiring self is *not* the only fix for that problem. You could also avoid shadowing. Which choice you make is up to you.