[swift-evolution] Proposal: Re-instate mandatory self for accessing instance properties and functions

David Waite david at alkaline-solutions.com
Sun Dec 13 12:20:10 CST 2015


> On Dec 13, 2015, at 2:40 AM, David Hart via swift-evolution <swift-evolution at swift.org> wrote:
> <snip>
> I agree that that would potentially add confusion to the grammar. I've always liked the @ and @@ prefixes of Ruby for accessing instance and class properties, but I agree that symbols like that would feel a bit foreign in Swift.
> 
I believe the interesting bit about Ruby in this case is that it only exposes variables through bound scope. self.foo means ‘call foo on object self’. 

So @foo is *not* shorthand in Ruby, it provides different functionality. This is similar to using this->foo vs self.foo in Objective C.

-DW

> David
> 
> On 13 Dec 2015, at 10:16, ilya via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> > But implicit self is confusing in a lot of code
>> 
>> On the other hand, it allows a logical explanation of how you can take code from global scope and put it into an instance scope:
>> 
>> let greeting = "Hello"
>> let name = "Michael"
>> 
>> func greet() {
>>     print("\(greeting), \(name)")
>> }
>> 
>> seemlessly becomes
>> 
>> class Greeter {
>> 
>>     let greeting = "Hello"
>>     let name = "Michael"
>> 
>>     func greet() {
>>         print("\(greeting), \(name)")
>>     }
>> 
>> }
>> 
>> > can (and does) lead to shadowing bugs,
>> 
>> There are simple strategies that help to minimize the amount of shadowing, e.g. 
>> 
>> - only expose the minimum necessary amount of names in any scope 
>> - break functions into small part so that it's easy to see all the local name declarations
>> - not use any globals, or at least name them in a visually different way (UppercaseCamelStyle)
>> - name properties and locals in a different way (classProperty, local_var)
>> 
>> Even without a formal code style, if you tend to make property names longer and local names shorter, your risk of shadowing goes down.
>> 
>> > .x and .f() to mark implicit self. I realize that this may conflict with enum usage.
>> 
>> This will lead to a lot of ambiguity:
>> 
>> func f() {
>>     let x = NSOperation()
>>     .name = "Name" // is it x.name <http://x.name/> or self.name <http://self.name/>??
>>    ...
>> }
>> 
>> >  If so, then use another marker. For instance :x or ^x or anything.
>> 
>> This is workable, but still I think this is one of the best points of Swift – the existence of instance scope where names are simply written as-is. This helps implementing patterns like "take a long function and make it into a struct with a bunch of small functions instead".
>> 
>> > is very difficult to reason about in diffs or any other interface that isn't an IDE (especially code review)
>> 
>> This is the point where I entirely agree, good code should be easily read in any context.
>> Again, may I suggest you take a look into using a style guide to differentiate visually between local and instance scope?
>> 
>> Ilya
>> 
>> On Sun, Dec 13, 2015 at 10:15 AM, Rob Napier via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> I wanted to reopen this discussion that seems to have trailed off. Requesting the return of self was my very first ask of Swift if I remember correctly (https://devforums.apple.com/message/1013085 <https://devforums.apple.com/message/1013085>). Continued work in Swift has both strengthened and modified that ask. Here are several of the examples discussed before:
>> 
>> https://gist.github.com/schwa/94b11dc0a7a331f46b25 <https://gist.github.com/schwa/94b11dc0a7a331f46b25>
>> https://gist.github.com/rnapier/478465d1b15e95b98b42 <https://gist.github.com/rnapier/478465d1b15e95b98b42>
>> https://gist.github.com/rnapier/4213dc64206b17df6935 <https://gist.github.com/rnapier/4213dc64206b17df6935>
>> https://gist.github.com/dwineman/d6c56ec0c0e2fdb761db <https://gist.github.com/dwineman/d6c56ec0c0e2fdb761db>
>> 
>> I get that it seems tedious to type (and read) "self." and I get that "self." is currently a hint that self might be captured (but doesn't actually mean that, since you can use self. without capturing, and sometimes have to, very often in init, so really it's basically meaningless for that use).
>> 
>> That's why I suggest using .x and .f() to mark implicit self. I realize that this may conflict with enum usage. If so, then use another marker. For instance :x or ^x or anything. But implicit self is confusing in a lot of code, can (and does) lead to shadowing bugs, and is very difficult to reason about in diffs or any other interface that isn't an IDE (especially code review).
>> 
>> Thoughts, David? I agree with your basic proposal; I just want to amend it.
>> 
>> -Rob
>> 
>>  
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151213/ff6e2c10/attachment.html>


More information about the swift-evolution mailing list