Poll: Do you do explicit or implicit self?

[Travis_Griggs]

I don't want to debate the one versus the other. There's big long threads that do that already. I'm pretty confident that the implicit self'ers are in the majority, but swiftformat options like "--self insert" make me think there's some small group of explicit'ers. I was curious how many (I recognize that is a pretty ad hoc polling location). Which do you do?

• Implicit When Possible
• Explicit Always

[Karl]

My preference is:

Explicit in initialisers, or when accessing generically-named data (e.g. count, length) from within a large, complicated function. Otherwise implicit.

[DevAndArtist (Adrian Meister)]

Explicit self everywhere where required, or in some rare cases for disambiguation and in every init. Other than that I rely on the implicit self.

[typesanitizer (Varun Gandhi)]

[In case you didn't know] You can do a poll in discourse using the 'Build Poll' option, that way people can answer your question without leaving comments for one or the other.

[Travis_Griggs]

Fixed, thank you!

[wbrian (W. Brian Gourlie)]

I use implicit self where possible, but only because AppCode orange-squigglies unneeded self qualifiers (I should probably figure out how to disable that lint).

On the other hand, I'm not sure how I feel about implicit return. I wish it was similar to rust where the last expression in a given block is implicitly returned, although optional semicolons in Swift conflict with that desire.

[tera]

implicit everywhere including escaping closures!
("explicit use of 'self' to make capture semantics explicit" doesn't make it "explicit"! what makes capture semantics explicit is capturing self in the closure capture list.)

[mickeyl (Dr. Mickey Lauer)]

Explicit everywhere. Made a habit thanks to decades of Python programming.

[stephencelis]

Explicit everywhere. Started with implicit everywhere thinking it would help call out where self was actually required and help identify retain cycles, but in practice found that readability, especially in pull requests, was greatly improved with explicit self.

[nikitamounier]

Agreed. I especially find it super confusing when people call a method using implicit self when they're inside the same type. For example:

struct Bar {
    func foo() {
        baz() // should be self.baz() for clarity
    }

    // .....
    
    func baz() { /* ... */ }
}

[Nobody1707]

It depends on the method. I find that things like formIndex(after:) read just fine with implicit self, but things like sorted() really want explicit self.

[tera]

somewhat tangential:

i found it interesting that despite of similarities between closures and local functions when using the latter it is not obvious that 'self' is captured:

class C {
    var x = 1
    
    func foo() -> () -> Void {
        
        let bar = { /* either [self] in */
            /* or self. */ x = 2
            /* is required, compilation error otherwise */
        }
        func baz() {
            x = 2 /* self. is not required here... 🤔 */
        }
        
        DispatchQueue.main.async {
            bar()
            baz() // case 1
        }
        
        // case 2:
        return bar
        // or
        return baz
    }
}

it feels more appropriate if "self." was required inside "baz", as it escapes in both 1 & 2 cases

[Heaney]

I like to be explicit where I can in my own personal projects, but when I’m working on larger code bases with multiple people, the project convention usually seems to be implicit where you can.

Being implicit keeps things lightweight, but I like the extra readability explicitly using self can give.

I’m enjoying seeing what others are posting on this!