* What is your evaluation of the proposal?
+1. I support this proposal, although I would be in favor of making it optional
via a command-line switch on the compiler, as a courtesy to those who don’t
agree.
* Is the problem being addressed significant enough to warrant a change to
Swift?
Yes. Implicit self has been, in my experience, an effective cloaking device for
bugs, from accidental property accesses after a shadowing variable has been
deleted to just plain weird things like the infamous NSView print bug, in which
calling print() to log something to the console ended up actually printing the
contents of the view onto paper and ink. It also makes code less readable, as
it is not immediately obvious whether the entity being referenced is a
property, a global, or a local variable.
One can, of course, enforce self. through a style guide, however, as others
have noted, coders are human. I myself have caught several accidental usages of
implicit self in my own code, and I imagine others have as well.
Reading some of the “nay” votes on this list, I started realizing that there is
a performance issue here, as well. Several people have commented on the
following pattern, inherited from Objective-C:
func doSomething() {
let foo = self.foo
self.barWithFoo(foo)
self.bazWithFoo(foo)
self.quxWithFoo(foo)
}
deriding the above pattern as being a “poor practice” which is only done to get
around the self requirement. My contention is that this is far from the case,
and that there are good reasons for the above pattern:
1) Accessing a property, in a class, is more expensive than accessing a local
variable. The above code would require three message sends and/or vtable
accesses instead of one, if it were not assigning the property to a local
variable. These unnecessary property accesses needlessly reduce the efficiency
of the program.
2) In a multi-threaded program, it is conceivable that the value of self.foo
could change in between accesses to it. If the logic of doSomething() does not
take this possibility into account (or protect itself with a locking mechanism
or some such), this could lead to all sorts of odd behavior.
The upshot is that treating property accesses as if they were local variables
can encourage developers not to keep in mind the costs and dangers of property
accesses.
* Does this proposal fit well with the feel and direction of Swift?
Yes. Despite what others have written, self.foo does not come across to me as
particularly verbose. Objective-C was a verbose language, but it was not
because of self. It was because
-methodNamesTendedToBeWrittenToLookALotLikeThisWithLotsAndLotsOfCamelCaseWords:thatWentOn:andOn:andOn:andOn:.
* 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 done Objective-C coding for quite a long time, and was never bothered by
the need to use self to access properties. I *was* bothered by the fact that
instance variables were implicitly referenced without self->, making them far
too easy to accidentally reference. I find it telling that almost everyone
eventually ended up standardizing on the underscore prefixes for ivar names,
just to avoid this issue.
Charles
> On Dec 16, 2015, at 12:55 PM, Douglas Gregor via swift-evolution
> <[email protected]> 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
>
> <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
> <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
> <https://github.com/apple/swift-evolution/blob/master/process.md>
>
> Cheers,
> Doug Gregor
> Review Manager
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
