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

[ilya]

> For me, readability has always been more important, as we spend most of
our time reading than writing code.
Agree.

> but they make code editing easier at the expense of readability.
Disagree. This really depends on the example. E.g. which is more readable:

struct Vector {
    var dx: Double
    var dy: Double
    var length: Double { return sqrt(dx*dx + dy*dy) }
}

vs

struct Vector {
    var dx: Double
    var dy: Double
    var length: Double { return sqrt(@dx*@dx + @dy*@dy) }
}

struct Vector {
    var dx: Double
    var dy: Double
    var length: Double { return sqrt(self.dx*self.dx + self.dy*self.dy) }
}



On Sun, Dec 13, 2015 at 12:40 PM, David Hart <david at hartbit.com> wrote:

> Hi Ilya,
>
> Why use a style guide when the language can enforce rules to eliminate the
> ambiguity?
>
> 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
>
>
> This helps implementing patterns like "take a long function and make it
> into a struct with a bunch of small functions instead".
>
>
> Both of your previous points make sense but they make code editing easier
> at the expense of readability. For me, readability has always been more
> important, as we spend most of our time reading than writing code.
>
> That's why I suggest using .x and .f() to mark implicit self.
>>
>
> 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.
>
> David
>
> On 13 Dec 2015, at 10:16, ilya via swift-evolution <
> 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 or 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> 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). 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/rnapier/478465d1b15e95b98b42
>> https://gist.github.com/rnapier/4213dc64206b17df6935
>> 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
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
> _______________________________________________
> 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/20151213/58e51123/attachment.html>