[Review] Require self for accessing instance members


(Douglas Gregor) #1

Hello Swift community,

The review of “Require self for accessing instance members” begins now and runs through Sunday, December 20th. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

  Cheers,
  Doug Gregor
  Review Manager


(Douglas Gregor) #2

All of the prior swift-evolution commentary on this proposal (which is nearing the 100-message mark) will also be considered, of course!

  - Doug

···

On Dec 16, 2015, at 10:55 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of “Require self for accessing instance members” begins now and runs through Sunday, December 20th. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

  Cheers,
  Doug Gregor
  Review Manager

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


(Hooman Mehr) #3

  * What is your evaluation of the proposal?

-1

Not much to add to the discussion.

  * Is the problem being addressed significant enough to warrant a change to Swift?

No. Although a suppressible/enforceable warning might be beneficial.

  * Does this proposal fit well with the feel and direction of Swift?

I don’t think so. It enforces a lot of visual clutter everywhere to provide some benefit for people with certain coding/naming habits.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A quick reading.

···

On Dec 16, 2015, at 10:55 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:


(Erica Sadun) #4

I vote against this proposal.

I believe instance-member access outside of closures is better addressed with in-house standards rather than language-mandated supervision. Swift's clarity and readability are its strengths and this proposal works against those design goals. I endorse using self when it makes sense to do so but I don’t like the idea of a heavy-handed universal language-mandate. If effort equates to "venting loudly and often about the inadvisable nature of this proposal", I have put significant effort into reviewing this proposal.

I hold my vote to be `self`-evident that not all language enhancements are created equal, and that we are endowed by our compiler with certain unalienable rights, that among these are simplicity, elegance, and the pursuit of our own coding standards.

-- Erica

···

On Dec 16, 2015, at 11:55 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of “Require self for accessing instance members” begins now and runs through Sunday, December 20th. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

  Cheers,
  Doug Gregor
  Review Manager

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


(Nick Shelley) #5

-1 from me.

My experience with Objective-C taught me that I'm bad at thinking about
retain cycles every time I write code in a block or closure. Only requiring
self in closures in Swift has been a great way for me to avoid the bugs
caused by introducing retain cycles when self is captured in closures. This
proposal takes that extra needed reminder away from me, which will result
in more bugs (as my experience with Objective-C requiring self everywhere
has shown).

···

On Wed, Dec 16, 2015 at 11:55 AM, Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote:

Hello Swift community,

The review of “Require self for accessing instance members” begins now and
runs through Sunday, December 20th. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change
to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have you used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Cheers,
Doug Gregor
Review Manager

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


(Ray Fix) #6

* What is your evaluation of the proposal?

My vote is to reject this proposal.

  * Is the problem being addressed significant enough to warrant a change to Swift?

I have been writing code that prefers the more succinct style since Swift was announced and have not run into readability issues. This proposal adds too much visual noise with very little benefit.

The UIViewController.title example is interesting but I think more of an indictment of inheritance. I would have been more open to a proposal that addressed this problem specifically rather than blanket requiring self everywhere. For example, in cases where you accessing non-private members from a base class, you might require self.

Giving up the compiler’s hint that you are making a circular retain in a closure is too important to give up.

  * Does this proposal fit well with the feel and direction of Swift?

This proposal adds too much boilerplate. I note that the Ray Wenderlich swift style guide whose priorities are for "shorter and more readable code” for conciseness prefers not writing self when not required. If including self everywhere truly helped readers understand tutorials better, you would expect to see an exception here.

  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Many successful languages(C++/Java) do not require you to reference “self" or “this" explicitly. In using them I have never once thought that they would be improved if doing so was a requirement.

Javascript does require referencing “this" but CoffeeScript makes a shortcut for it to reduce visual noise. this.thing in Javascript is written @thing in CoffeeScript.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I read the proposal carefully and considered all of the points of the author and thought about my own experiences reading Swift code and teaching Swift over the last couple years. Because of time constraints, I wasn’t able to conduct an in-depth study on the subject.

Ray Fix


(Paul Cantrell) #7

Please forgive the length of the treatise that follows. It touches on some strong feelings I have about code as information design.

┝━━━ What is your evaluation of the proposal? ━━━━┥

I strongly oppose this proposal.

Despite the author’s claims, it reduces the signal/noise ratio of code, and thus has a negative impact on readability which outweighs its marginal safety benefit.

Developer opinion is strong, but strongly divided. Can one answer work for everyone? Consider: Teams who like this proposal have easy recourse if it is rejected: they can enable a build-time lint checker which will makes look and feel almost exactly like a language feature. However, teams who prefer implicit self have no recourse if this proposal is accepted.

This is, and should remain, a matter of style and taste left to individual teams.

┝━━━ Does this proposal fit well with the feel and direction of Swift? ━━━━┥

No, despite the proposal’s arguments to the contrary.

• This proposal confuses verbosity with clarity.

In its support, the proposal quotes Swift API guidelines that talk about clarity at point of use taking precedence over brevity. Note, however, that those guidelines do not speak against brevity either; they merely call out obsessive code golf as a fool’s errand.

Clarity comes neither from brevity nor from verbosity, but from mindfulness about which information to express. Both excessive conciseness and excessive repetition injure clarity.

In several places, these very same Swift guidelines that warn against brevity for its own sake also identify brevity as a way of achieving clarity. For example, in the “Omit Needless Words” section, they state, “More words may be needed to clarify intent or disambiguate meaning, but those that are redundant with information the reader already possesses should be omitted.”

That section proceeds to recommend that this is bad:

    allViews.removeElement(cancelButton)

… and this is clearer:

    allViews.remove(cancelButton)

…because the cancelButton argument already is of type Element.

Take note! The guidelines consider information redundant, and thus inadvisable, merely because it is already present in inferred information that may not have ever been stated explicitly near the call site. A “self.” that adds no further information certainly runs afoul of this principle.

This brings us to the core of my rejection:

  Anything that is widely repeated becomes invisible.

This truth shoots an arrow through the heart of the preposterous argument that “explicit > implicit, always.” Imagine how ridiculous our code would look if we truly took this to heart! Instead of “let x = 1 + 1”, we'd have “allocate(constant, stack_allocated, unsynchronized, 32 bits) → name(“x”, locally_scoped); x ← integer_addition(1, 1, min: -2^31, max:2^31-1, overflow: exception)” … or wait, no, even that leaves things such as the meaning of “integer” implicit. Explicit always better? Really? Shouldn’t we then have to state the Peano Axioms every time we use an integer? Even LLVM IR leaves some things unstated.

Language design is all about what we choose to make implicit. Explicitness has no inherent virtue, and does not by itself justify this proposal. Explicitness is useful only when it is not redundant. Mandating “self.” creates redundancy. Leaving it to programmer discretion allows clarity in all cases — both when clarity is explicit and when clarity is concise.

• Swift adds language features that reduce boilerplate; this proposal increases it.

(Yes, we’re still in the “Does this proposal fit well with the feel and direction of Swift?” section.)

Some languages, such as C and Java, show a preference for minimizing the number of language constructs, even if this comes at the expense of repetitive keystrokes — and repetitive reading. (Witness Java’s approach to properties, for example.)

Though that approach does have the advantage of keeping the language smaller, easier to learn, and more stable over time, Swift comes down firmly on the other side: it seeks to eliminate boilerplate, and is willing to add language features to accomplish this when the benefits are clear. For example: stored properties and their surrounding features (willSet, didSet, lazy, etc.), optional unwrapping conveniences (if let, ??, etc.), default struct initializers, default arguments, etc.

This proposal runs contrary to Swift’s dislike of boilerplate and senseless repetition.

• This proposal runs contrary to Swift’s state purpose of being useful in a wide variety of programming domains.

One of the surprising things that this C/C++/Java developer learned from Ruby is that there’s tremendous value when a language’s syntax can get out of the way to let library authors create domain-specific idioms.

Ruby’s primary technique for doing this is leaning on implicit self (and no-parens method calls; a different question!) to provide a scope in which, for example, code describing a domain model or a state machine or an HTTP router can use only language relevant to the task at hand. Swift as it stands is reasonably friendly to this approach.

Mandatory “self.” would rule out this sort of programming — or least many of the best technique for implementing it.

Chris L has stated that he’d like to see Swift work in a wide variety of programming contexts. This proposal runs counter to that goal.

┝━━━ Is the problem being addressed significant enough to warrant a change to Swift? ━━━━┥

Scope errors and name collisions are indeed a source of programmer error, and it’s worth considering ways to address them.

However, the specific problem this proposal addresses is very narrow. Because of Swift’s lowercase letter naming convention, its relative paucity of global variables and functions, and the relatively low use of method-local functions, 99% of the problem this proposal solves is confusing local variables with member variables. That specific error is already flagged in common cases by other compile-time sanity checks, such as nonsensical self-assignments (foo = foo), use of a local variable before its declaration, and initializers completing before all stored properties are initialized.

While these compiler checks clearly do not cover all accidental uses of a local func / var where a member was intended, they leave the remaining safety gap filled by this proposal fairly small.

If Swift were to address the problem of scope confusion, it should do so in a way that covers more than this narrow subset of mistakes.

┝━━━ If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those? ━━━━┥

I’ve worked in the following languages which have implicit self/this:

Ruby*
Java
C++

…and in the following languages which do not have it:

Objective-C
Javascript
Coffeescript
Python

(And gosh, did THINK C have it? I honestly can’t remember.)

My arguments above reflect my experiences with languages of both kinds.

* I realize that in the discussion thread, Ruby’s @ came up as an alternative to explicit self. However, @ ≠ self in Ruby; instead, it distinguishes member variables from methods — and Ruby properties implemented as methods. Wherever it is legal in Ruby to say “self.”, if there’s no name conflict, then it’s also legal to leave it out.

┝━━━ How much effort did you put into your review? A glance, a quick reading, or an in-depth study? ━━━━┥

Probably too much — or perhaps not enough into editing it down! :stuck_out_tongue:

Cheers,

Paul

···

On Dec 16, 2015, at 12:55 PM, Douglas Gregor <dgregor@apple.com> wrote:

Hello Swift community,

The review of “Require self for accessing instance members” begins now and runs through Sunday, December 20th. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

  Cheers,
  Doug Gregor
  Review Manager

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


(Guillaume Lessard) #8

I vote against this proposal.

The stated “advantages" of this proposal are mostly matters of taste and opinion and, as such, are not real advantages at all. Furthermore, the proposal is silent as to the advantage of requiring `self` in `struct` and `enum` definitions.

The only stated advantage that seems relevant is that it lets the compiler “warn users (and [avoid] bugs) where the authors mean to use a local variable but instead are unknowingly using an instance property (and the other way round)."

Given that being the sole genuine “advantage” of this proposal, a clear alternative is to improve and strengthen warnings for some cases of variable shadowing. I might not be opposed to that.

* Is the problem being addressed significant enough to warrant a change to Swift?

No

* Does this proposal fit well with the feel and direction of Swift?

No. It trades an increased verbosity in all applicable cases for a small clarity advantage in a few cases.
It is not Swift-like at all.

* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I read too much of the thread, and have written much Swift code, including a *lot* of closures.

Early on in my use of Swift I regularly wrote `self` in places where it was not required.
Upon reviewing my code, I removed the majority of those for clarity.

Sincerely,
Guillaume Lessard


(Preston Sumner) #9

While I acknowledge the issues raised by the proposal, I don’t think they're crucial enough to warrant changing the language.

One concern is that I expect people would simply sidestep the requirement by getting all their accesses through self out of the way early, as they do in Objective-C:

  // Store a bunch of local variables to the stuff we want to work with.
  let alpha = self.alpha
  let beta = self.beta
  let gamma = self.gamma
  var results = self.results

  // Actually do the work we wanted to do.
  let result = calculateResultWithAlpha(alpha, beta: beta, gamma: gamma)
  results.append(result)

As in Objective-C, these preambles can be mildly annoying to read and write, depending on your temperament. More importantly, a bug exists in the example: the results array is a copy, so the calculated result doesn’t get appended to the instance variable as intended. The proposal trades one set of potential gotchas for another, as modifications to internal value types would require either always accessing them through self or remembering to propagate local changes to their respective instance variables at the end of work.

Good points can be made by both sides in favor of preferring a particular style, while no sufficiently persuasive points have yet been made for changing the language to prohibit either one. Thus—like tabs versus spaces or eating bread buttered-side up or buttered-side down—I think this is a style choice better enforced at the project level.

Preston

···

On Dec 16, 2015, at 11:55 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of “Require self for accessing instance members” begins now and runs through Sunday, December 20th. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

  Cheers,
  Doug Gregor
  Review Manager

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


(Alejandro Martinez) #10

I've been following the thread for some days and being the community quite separated in this makes it a hard decision.

Honestly I've been using self. in my Swift code most of the time, for me it makes things more explicit and removes any confusion that can happen. That said, I say "most of the time" because is really true that it feels nicer to not include it.

I would like to point out that being explicit is not necessary a bad thing, as Swift already force us to being explicit in some ways (optionals, throws, etc) as the proposal says, but specially that, IMHO, we should not decide if things that affect directly the code that we write and, specially, read should be omitted because another tool makes it obvious. In other words, that an IDE colorizes the text is not enough to discard it. We read a lot of code from the internet, specially PR, and we can not rely on having always an IDE to make things explicit.

That said, seeing that the community is so separated in this and that the language doesn't enforce it already (which looks like the core team didn't think that it that important for being part of the core language) I would say that having this enforced by a linter or a compiler warning (that can be disabled) may be enough.

Sorry for not having a stronger opinion, but I wanted to add my opinion to the review :wink:

PS: I agree that maybe the proposals should contain more of the opinions in the mailing list, at least in cases like this that have been so many mails and not everyone can keep up with it. Cheers.

···

El 16 dic 2015, a las 18:55, Douglas Gregor via swift-evolution <swift-evolution@swift.org> escribió:

Hello Swift community,

The review of “Require self for accessing instance members” begins now and runs through Sunday, December 20th. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

  Cheers,
  Doug Gregor
  Review Manager

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


(nschum) #11

-1 (in it’s current form)

I’m concerned about decreasing the signal/noise ratio.
The current way is similar to type inference. We can’t immediately see the type, but tool support makes it easy to retrieve the information if needed. And most of the time, i.e. when just scanning the code, there is simply less information to work through.
With less syntax, the code structure becomes clearer than when every second word is “self”.
As such, I don’t think the proposal in its current form fits well with Swift, which is very good at keeping code “to the point”.

I wonder if leaving out “self”, but keeping the dot would be a better alternative. There is precedent in Swift (c.f. enums), the dot is easier to ignore when skimming the code and it’s still immediately obvious when you want to know.
Ruby does something similar (using @) and it feels muss less heavy than “self.” in Objective-C while having most of the benefits. Any other single character would work, too, of course.

Example:

class Person {
    var name: String = "David"
    func foo() {
        print("Hello \(.name)")
    }
    
    func bar() {
        .foo()
    }
}

I think the problem is significant enough that it might warrant *a* change to Swift, but not the proposed one. The costs are higher than the benefits compared to my current solution (which is very clear syntax highlighting).
I do question if the problem occurs frequently enough (or at all) when it comes to methods.

Nik

···

On 16 Dec 2015, at 19:55, Douglas Gregor <dgregor@apple.com> wrote:

Hello Swift community,

The review of “Require self for accessing instance members” begins now and runs through Sunday, December 20th. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

  Cheers,
  Doug Gregor
  Review Manager

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


(Lily Ballard) #12

After having considered this for a while, I'm still strongly opposed to
this proposal. I think the relevant reasons have already all been cited
in this thread.

I also think there's a good opportunity here for someone to take
SourceKit and write their own linting tool, to allow people to establish
their own conventions and check them with a build script.

-Kevin Ballard

···

On Wed, Dec 16, 2015, at 10:55 AM, Douglas Gregor via swift-evolution wrote:

Hello Swift community,

The review of “Require self for accessing instance members” begins
now and runs through Sunday, December 20th. The proposal is
available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md

Reviews are an important part of the Swift evolution process. All
reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the
direction of Swift. When writing your review, here are some questions
you might want to answer in your review:

* What is your evaluation of the proposal? * Is the problem being
addressed significant enough to warrant a change to Swift? * Does
this proposal fit well with the feel and direction of Swift? * If you
have you used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those? * How much
effort did you put into your review? A glance, a quick reading, or an
in-depth study? More information about the Swift evolution process is
available at

https://github.com/apple/swift-evolution/blob/master/process.md

Cheers, Doug Gregor Review Manager

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


(David Waite) #13

  * What is your evaluation of the proposal?

-1

  * Is the problem being addressed significant enough to warrant a change to Swift?

There are enhancements around this problem which are worthwhile in pursuing, but I don’t believe this verbosity is the right approach.

Imagining a 3D point struct (possibly the worse case example):

var length:Double {
  get {
    return self.x*self.x+self.y*self.z+self.z*self.z
  }
}

this is significantly harder to read and maintain than the implicit self code
var length:Double {
  get {
    return x*x+y*z+z*z
  }
}
There is a bug in the two functions - which version is easier to spot?

So for the given points:

More readable at the point of use.
I strongly agree this has been shown. The author may have meant to say the code is less ambiguous, but it is certainly less readable in my example and the examples the author gave.

More consistent than only requiring self in closure contexts.
This is true, but I actually would like to eventually propose not requiring self in closure contexts
Less confusing from a learning point of view.
I cannot speak to this, languages are taught different now, and I was self-taught until college. The specification of this when I was learning C++ in college was an advanced feature - we did not use ‘this’ in my first year. Once Java came about, initializers often require “this" because of parameters shadowing properties, which was the first time I really started using the keyword.

Lets the compiler warn users (and avoids bugs) where the authors mean to use a local variable but instead are unknowingly using an instance property (and the other way round).
I believe that warning the user that a variable which is being used is shadowed in all cases other than let x=x is a far better solution. This is admittedly still more ambiguous than requiring the user to explicitly reference the context of the variable/function, but there is an expectation of API knowledge when working *inside* of a class or subclass that remains whether you are explicit or implicit in referencing self.

  * Does this proposal fit well with the feel and direction of Swift?

I believe it represents a syntactical regression.

  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I have not. I know Python and Rust have explicit self parameters in function declarations, but even then they have implicit usage of that self parameter.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Somewhere between a quick reading and an in-depth study, as the discussion is not represented by the proposal, and the mailing list discussion got too big for me to follow 100%

-David Waite (DW)


(Pierre Monod-Broca) #14

* What is your evaluation of the proposal?

I’m strongly against it.

* Is the problem being addressed significant enough to warrant a change to Swift?

I don’t think so.

I, personally, never encountered a bug due to this problem, and it would be really easy to fix.

I hear that such bugs might be difficult to track, and there might be ways to help to detect them, but I’m not convinced by the proposed solution.

It seems more like a matter of taste, and the proposed solution would remove choice.

* Does this proposal fit well with the feel and direction of Swift?

I don’t think so.

I think Swift should be concise when that doesn’t hinder clarity. (And in this case, I’m afraid it is explicitness that would hinder clarity).

Also, it seems to me implicit self makes properties and methods first-class citizens, and I think they should be.

* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Yes: Objective-C, and I was glad, migrating to Swift, to get rid of all those explicit self.

* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I followed most of the thread.


(Step C) #15

* What is your evaluation of the proposal?
-1. I do not support the proposal.
    * Is the problem being addressed significant enough to warrant a change
to Swift?
No. When Swift was first announced, the implicit self was one of the things
we argued about at the ranch. I was initially opposed. However after
working with the language for a short time, I slowly became convinced it
was not as significant an issue as I thought at first. In Objective-C it is
common to do something like:
NSString *foo = bar;
foo.baz = 1;
foo.blargh = 2;
self.foo = foo; // Don't forget to set the property using the temporary
local!
This is another way to reduce the syntactic noise and baggage of otherwise
adding "self" on each line, and it makes the code's intention clearer.
However this has led to many (admittedly easy to find) bugs where I've
forgotten to assign the temporary local variable back to self at the end.
There's a similar pattern with a closure that can help prevent that issue -
but neither of these are necessary in Swift if your semantics don't need
them.
In addition, I have been teaching Swift (via Big Nerd Ranch courses of
various kinds) since Swift was released. Implicit self has not led to as
much confusion as I was initially concerned with. I do think it allows some
misconceptions to linger longer, but the tradeoff is it makes the language
easier to start with - the language is less intimidating initially because
it supports common patterns such as this.
Finally I'll note that type inference is essential to Swift, and yet that
leaves a lot of information implicit as well in the plain-text code. Both
that and shadowing can cause as much confusion as implicit self. Others
have already explained the other scoping issues that are not addressed by
this proposal.
    * Does this proposal fit well with the feel and direction of Swift?
No. Swift carefully and nicely rebalances clarity to also value brevity.
Others have explained well already how signal-to-noise is important. I
agree with those sentiments and think the best balance has been struck on
this issue by not requiring self.
Swift also seems to me a somewhat tool-centric language, for better and
worse. Many commenters have made the valid point that leaning on syntax
highlighting is not sufficient (or even possible) for many developers. Not
only is there the colorblind issue, but many of us regularly read code in
emails and other locations where tool assistance is not available. I do not
think that argument weighs strongly enough in this case, where in practice
you should usually have sufficient information in the code if you need to
determine local vs. object (though I'm sure examples can be constructed to
the contrary).
    * If you have you used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
I've compared to Obj-C above. Obj-C also values readability, but with no
weight given to brevity (it almost considers verbosity a virtue at times).
As much as I enjoy the language, Swift's comparative terseness allows more
expressivity, while not taking it as far as Ruby or Perl.
    * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
I followed the discussion, and considered this issue when Swift was first
announced all the way through release. I've taught Swift to many classes,
some largely new to programming and many coming from an Obj-C background. I
have not done an in-depth study but I consider myself relatively
well-informed on this issue.

Sincerely,
Step Christopher

Step Christopher
Big Nerd Ranch, LLC
schristopher@bignerdranch.com

···

On Wed, Dec 16, 2015 at 1:55 PM, Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote:

Hello Swift community,

The review of “Require self for accessing instance members” begins now and
runs through Sunday, December 20th. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change
to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have you used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Cheers,
Doug Gregor
Review Manager

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


(Patrick Gili) #16

Hello Swift community,

The review of “Require self for accessing instance members” begins now and runs through Sunday, December 20th. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?

This proposal does not improve Swift.

  * Is the problem being addressed significant enough to warrant a change to Swift?

No.

  * Does this proposal fit well with the feel and direction of Swift?

No. From the first time I saw Swift, I felt it represented the best aspects of my favorite modern languages, such as C# and Ruby. This changes would represent a step backwards.

  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Object-C: too verbose for my taste. Swift was a welcome change for developing OSX/iOS application.
Python: too strict for my taste. Ruby became my go-to alternative for scripting. I saw Swift borrowing or improving on many of Ruby's concepts.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I have carefully read every message posted to the mailing list. I did a little research to confirm my experiences with languages I have used over the last 37 years, but not a lot.

···

On Dec 16, 2015, at 1:55 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

  Cheers,
  Doug Gregor
  Review Manager

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


(Rudolf Adamkovič) #17

After careful reading through all the arguments, I'm now in the -1 camp too.

The "visual noise" examples and reasoning about consistency with the rest of the language totally got me.

P.S. I really liked the idea to use a dot instead of dot self but yeah, dot is already reserved for enums.

R+

···

Sent from my iPhone

On 16 Dec 2015, at 19:55, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of “Require self for accessing instance members” begins now and runs through Sunday, December 20th. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

  Cheers,
  Doug Gregor
  Review Manager

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


(David Owens II) #18

* What is your evaluation of the proposal?

+1.

* Is the problem being addressed significant enough to warrant a change to Swift?

Yes. I believe that is much clarity lost. I also really dislike the inconsistent requirement of self in multiple contexts. When we talk about language rules, I really think it’s a disservice when there needs to be a lot of qualifiers. You use “self” in this context, but you don’t have to in this one, well, unless you then do that… This kind of explanation, in my opinion, signals a design flaw.

I’ve never encountered a bug in a language that requires self to access its members with shadowing, but I have had the opposite experience many, many times. While this doesn’t fix all shadowing issues, I do think it fixes the vast majority of them.

* Does this proposal fit well with the feel and direction of Swift?

Yes.

* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I’ve used languages on both sides. Most recently, I’ve been working with TypeScript. I don’t know the language well (at all really), it requires self for member access. I have to say, it’s really been a help for understanding what is where.

* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I’ve read through the threads and proposal and experience from languages that don’t require this and do.

-David


(Jed Lewison) #19

I’m not in favor of this proposal, and rather than repeat arguments that have already been made, I thought I’d share a small piece of data from the project I’m working on to illustrate the impact of implicit self in terms of reducing repetitive boilerplate cruft.

Our project consists of a legacy ObjC code base for an iOS app and a new version written entirely in Swift. The feature set is largely the same in both code bases, so it’s a good A vs B comparison.

In the Objective C version of the app, there are ~25,000 explicit references to self. (Keep in mind that this could easily have been a much bigger number if there weren’t such pervasive usage of ivars in the code.).

In the Swift version, there are ~1,000 explicit references to self, mostly in initializers and when passing self as an argument to a protocol — and about 10% of those would disappear with the proposal to allow implicit references to self with a strong capture list.

I know self is just a 4-letter word, and I know Swift’s goal isn’t to reduce character count simply for the sake of reducing character count, but it least for our project, avoiding “self”-blindness has really mode code more readable.

···

On Dec 16, 2015, at 1:55 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of “Require self for accessing instance members” begins now and runs through Sunday, December 20th. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

  Cheers,
  Doug Gregor
  Review Manager

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


(Tracy Keeling) #20

I just want to throw in a +1 for making self mandatory. It is very
confusing for it to be optional.

As far as the discussion on warning against shadowed variables.... I think
the warning is useful outside of constructors, but I am more ambivalent on
that.

···

On Wed, Dec 16, 2015 at 10:55 AM, Douglas Gregor <dgregor@apple.com> wrote:

Hello Swift community,

The review of “Require self for accessing instance members” begins now and
runs through Sunday, December 20th. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change
to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have you used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Cheers,
Doug Gregor
Review Manager

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