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

[Dennis Lysenko]

@Andrew: I agree that the discussion got a little sidetracked with people
debating whether self should be required at all in closures. I personally
think that your proposed solution may lead to needless ambiguity and
confusion with regards to self-capture, and I would be careful with
bringing it up as it could be a point of contention that may derail the
discussion further. I personally don't agree with it but will reserve my
judgment in the interest of staying on the topic of mandatory self.

Could anyone provide a reasonably unbiased round-up of the pros/cons so far
presented regarding required self capture?

To start, on the pro side I have heard --
- Differentiates locals and ivars, making code ostensibly more readable
- Makes code more refactorable (proposed by me, counterargument: it may not
be good to be able to move code around willy-nilly to and from closures
when considering capture semantics)

And on the con side, I have heard --
- Annoying to do
- Makes it harder to move from local to instance context
- Makes code ostensibly less readable through "self" proliferation

Unless I missed something (very possible seeing as I believe I've entered
this discussion somewhat late), the rest seems to be anecdotal data and
there does seem to be a solid split between the two schools.

On Sun, Dec 13, 2015 at 5:14 PM Andrew Brown via swift-evolution <
swift-evolution at swift.org> wrote:

> I think the requirement to use self in closures complicates the
> discussion.  Perhaps if this could be modified first it would help.
> Perhaps instead of self to indicate capture, we should use
> weak/strong/unowned etc as keywords to be explicit about the type of
> capture.
>
> then the discussion on self wouldn't be side tracked with this?
>
>
>    1. class HTMLElement {
>    2.
>    3.
>    4.   let name: String
>    5.   let text: String?
>    6.
>    7.
>    8.   lazy var asHTML: Void -> String = {
>    9.     if let text = unowned.text {
>    10.       return "<\(weak.name)>\(text)</\(weak.name)>"
>    11.     } else {
>    12.       return "<\(unowned.name) />"
>    13.     }
>    14.   }
>    15.
>    16. }
>
>
> ABR.
>
> On 7 Dec 2015, at 01:10, David Hart via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Hi Nick,
>
> I understand the quote "This makes the capturing semantics of self stand
> out more in closures”, but this is a very weak statement in Swift for me.
> Let me try to explain.
>
> If we use the try keyword as an example:
>
> try foobar()
> barfoo()
>
> If the previous lines of code compile without error, we know without a
> shadow of a doubt that foobar is a throwing function and that barfoo does
> not throw. The compiler will not compile the first line without the keyword
> and would not allow it in on the second line.
>
> Now if we go back to the example of self in closures:
>
> foobar({
> print(self.description)
> })
>
> The self keyword in the previous lines of code does not tell us anything
> at all:
>
>
>    - self might have been forced by the compiler to warn us.
>    - self might have been a programmer choice if the closure was
>    non-escaping.
>
>
> And the reverse:
>
> barfoo({
> print(description)
> })
>
> This also does not tell us much:
>
>
>    - The closure might be non-escaping.
>    - description might be referring to a local variable (which we missed
>    the declaration) shadowing the instance property in an escaping closure.
>
>
> In both of these last examples, we can’t tell by having a quick look at
> the code at the point of call if we should really be careful about memory
> or not.
>
> With the proposition, self gets some meaning back: it indicates which are
> local and which are instance properties.
>
> David.
>
>
> On 06 Dec 2015, at 23:55, Nick Shelley via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I like that self is only required in closures because it serves as a good
> reminder that there are memory and safety implications with using self in a
> closure, such as creating retain cycles or having the closure run after
> self has been deallocated.
>
> I can't seem to find an official Apple Swift style guide, but github's (
> https://github.com/github/swift-style-guide) suggests only using self in
> closures with the rationale: "This makes the capturing semantics of self
> stand out more in closures, and avoids verbosity elsewhere."
>
> On Sat, Dec 5, 2015 at 3:16 AM, Yichen Cao <ycao at me.com> wrote:
>
>> Teaching wise, its much less confusing for self to be required so
>> students don't mix up instance properties and local vars. Especially when
>> self is required in closures, it confuses students. If self is mandatory
>> for all instance properties, it would be so much clearer and much easier to
>> read.
>>
>> Yichen
>>
>> On Dec 5, 2015, at 18:11, swift-evolution-request at swift.org wrote:
>>
>> Re: Proposal: Re-instate mandatory self for accessing
>>      instance properties and functions (David Hart)
>>
>>
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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/20151214/646e47fe/attachment.html>