[swift-users] Future(of: self.references)?

[Charles Srstka]

While this makes sense in principle, it is far too easy to accidentally access the wrong member because something was shadowed. The very fact that the core team had to add a special-case warning for NSView.print() to the compiler itself demonstrates how problematic this can be.

Oh well. When the core team rejected the proposal, part of the rationale was that this could be done with a linter; does anyone know if anything to do this was ever written as an Xcode extension? As coincidence would have it, I ran into an issue caused by the implicit ‘self.’ behavior just yesterday.

Charles

> On May 23, 2017, at 12:00 AM, Kelvin Ma via swift-users <swift-users at swift.org> wrote:
> 
> As someone who is very in favor of using `self` everywhere, I’ve come to the conclusion that the easiest way to use `self` everywhere is to write `self` everywhere. I write Swift as if `self` were mandatory, and as that email argues, that’s good enough for me. Personally I find self-less code harder to read, but it’s not a big enough difference for me to argue for pushing it on everyone else. 
> 
> On Mon, May 22, 2017 at 8:56 PM, Greg Power via swift-users <swift-users at swift.org> wrote:
> Hi Travis,
> 
> I’m certainly not a core contributor, but I could point you to the rejection email for this proposal, which you might not have seen:
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/005478.html
> 
> It states that the core team felt that the proposal was not the right direction for Swift, and lists a few reasons.
> 
> The main reason appears to be that enforcing a mandatory self for instance members would increase the visual clutter of the language, which is counter to Swift's goals of clarity and minimal boilerplate.
> 
> That email links to Paul Cantrell’s response to the proposal, which is also a really good (and elucidating) read: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002910.html.
> 
> No need for flame or heat!
> 
> Regards,
> 
> Greg Power
> 
> 
>> On 23 May 2017, at 7:28 am, Travis Griggs via swift-users <swift-users at swift.org> wrote:
>> 
>> I’m trying to figure out how to ask this question without generating flame and heat. Like tabs and spaces, under_scores and camelCase, whether or not one thinks that a message dispatch receiver should be explicit or implicit seems to be highly personal, (I think*) based on where/how you learned programming, especially object oriented paradigms. Personally, I agree with Matt Neuberg and this Swift proposal (https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md). But I recognize there’s a community of others out there that think otherwise, and I’m not interested in trying to convert them to my approach.
>> 
>> What I *am* curious about is is what the core contributors/architects/designers seem to prefer? Is there any sort of consensus, or at least majority, that those doing the core work lean towards? They don’t have to convince me or vice versa. It’s just frustrating when collaborating with open source projects, that in this one area, there’s really no direction I’ve seen come forth.
>> 
>> For example, when Swift was waffling between functional and message oriented, I heard Chris Lattner (and have since seen in style guides) recommendations that if you can bind some behavior to data, you should, rather than leaving it a free function. That was nice to hear, and not just because I agreed. It was just nice to know which way the language would be leaning.
>> _______________________________________________
>> swift-users mailing list
>> swift-users at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
> 
> 
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
> 
> 
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users