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

[ilya]

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151213/dc391324/attachment.html>