Put me firmly in the pro-warning camp. If enforcing manual synthesis of ivars
(something I never understood the brouhaha about) warranted a warning flag in
clang, I think requiring self should at least merit consideration. It certainly
has a much greater potential for bugs than automatic ivar synthesis.
Charles
> On May 18, 2016, at 11:44 PM, Krystof Vasa via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> Thanks for the link, I'll definitely keep my eye on it, though since there
> are two large camps siding with either side, I don't see the harm making this
> proposal an optional warning of the compiler that would be off by default and
> those wanting to stay on the safe side would enable this and get a warning.
>
> BTW another example of what this would prevent:
>
> On OS X, all views (NSView) have a print(_:) method. So whenever you write
> within your code print("something"), it actually invokes the printing method
> (since its argument is AnyObject?) - if you indeed want to print something to
> the console, you need to use Swift.print("something") which is incredibly
> annoying mostly when you forget about this and all of sudden you get print
> dialogs instead of a log in the console.
>
> Yes, it's shadowing, but with this one, you can't do anything about and there
> will always be cases of shadowing - the more dangerous when you don't know
> about them.
>
> Krystof
>
>> On May 19, 2016, at 6:32 AM, Félix Cloutier via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>> That proposal might be one of the first early proposals to really get a lot
>> of attention. My take out of the experience is that people (me included in
>> this case) will yell very loudly if you try to enforce your coding standards
>> through the compiler.
>>
>> There is an open bug on SwiftLint
>> <https://github.com/realm/SwiftLint/issues/321> to add a rule that enforces
>> using self to access member variables. It might be worth taking a look.
>>
>> Félix
>>
>>> Le 17 mai 2016 à 22:09:44, Krystof Vasa via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :
>>>
>>> Hi there,
>>>
>>> I've been an OS X developer for over a decade now and was a huge fan of
>>> ObjC, implementing ObjC runtime into FreeBSD kernel as a intern at
>>> Cambridge University and my Masters thesis was a modular ObjC runtime that
>>> ran on Win 3.11. With the advance of Swift, it was clear to me, however,
>>> that this is a point to say goodbye to ObjC and move to Swift.
>>>
>>> And so, I've migrated all my projects over 5 months into Swift, which is
>>> over 200 KLOC of code, with one project being 90 KLOC. This has lead
>>> unfortunately to various hiccups due to bugs in Swift, Xcode, compiler,
>>> where I was unable to build a project for a month, etc. - I've filed 84 bug
>>> reports at bugreport.apple.com <http://bugreport.apple.com/> over the past
>>> few months regarding developer tools (including Swift) and have begun
>>> closely watching the evolution of Swift.
>>>
>>> While I strongly disagree with the rejection of SE-0009, I understood the
>>> reasoning that it's a boilerplate to keep adding self. in front of all
>>> variables. I personally always refer to self when accessing instance
>>> variables (and methods), unless they are private variables starting with
>>> underscore. I know the underscore thing isn't very Swift-y, but on the
>>> other hand, reading the code you immediately know you are dealing with a
>>> private instance variable, not something local.
>>>
>>> This was until I spent 2 hours chasing a bug that was caused by the exact
>>> issue this proposal was trying to prevent. I was furious.
>>>
>>> a) When you read someone elses code and you see myVar.doSomething(), you
>>> assume it's refering to a local variable. Which is incredibly confusing, if
>>> this is an instance variable. Swift is all about compile-time checks and
>>> this is where it fails.
>>>
>>> b) If you indeed decide not to go with this proposal, please consider
>>> adding a warning option. When you take a look at LLVM warning options, I
>>> bet there would be a place for this. Let the user decide. I personally
>>> would immediately turn it on on all my projects. Don't make it an error,
>>> make it a warning.
>>>
>>> I speak to you as someone with quite a huge real-life experience with
>>> Swift, mainly in the last year - the question whether to force the
>>> reference to self is something that may be dividing the community, but I
>>> believe that most people with more developing experience would be all for
>>> this. At least as an option.
>>>
>>> Sincerely yours,
>>>
>>> Krystof Vasa
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
