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

[Dennis Lysenko]

Nick, thanks for clarifying. Perhaps we could require an explicit [strong
self] in the cases where it is implicit, and Xcode autocomplete would
insert that any time it inserted a closure?

On Mon, Dec 14, 2015, 12:30 AM Nick Shelley <nickmshelley at gmail.com> 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.
>
>
> 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/20151214/75d9d3b9/attachment.html>