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

Nick Shelley nickmshelley at gmail.com
Sun Dec 13 23:30:05 CST 2015 

>
> @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.


I think you misunderstood Andrew's point.

>From what I understand, the main reason that self is required in closures
and not elsewhere is to serve as a compiler-enforced reminder about the
potential pitfalls of using self within closures (which I happen to think
it does well). Unless and until a different way of calling out those
pitfalls is proposed and accepted (as Andrew was suggesting), that point is
an essential part of the discussion IMO.

I don't think Andrew was suggesting that the discussion got sidetracked,
but realized that these two points can't be separated as the language
stands today, and was proposing a way to make them separate by
discontinuing the use of self as the way to call out capture semantics in
closures. At least that's what I understood when he said (regarding the use
of self in closures) "Perhaps if this could be modified *first* it would
help." (emphasis mine)


> 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
>

You forgot "Makes capture semantics of using self inside of closures less
apparent." I consider this the main con of the current proposal, and it
seems others do as well.



On Sun, Dec 13, 2015 at 8:55 PM, Dennis Lysenko via swift-evolution <
swift-evolution at swift.org> wrote:

> @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
>>
>
> _______________________________________________
> 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/ac1daa48/attachment.html>

More information about the swift-evolution mailing list