[swift-evolution] [Review] Require self for accessing instance members

[Charles Srstka]

* 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 <swift-evolution at 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 <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
> 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/20151219/5636ee04/attachment.html>