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

[Andrew Brown]

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?

class HTMLElement {

  let name: String
  let text: String?

  lazy var asHTML: Void -> String = {
    if let text = unowned.text {
      return "<\(weak.name)>\(text)</\(weak.name)>"
    } else {
      return "<\(unowned.name) />"
    }
  }
}

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