I agree that it shouldn't be mandatory, but voluntary, even though I do not
support it. E.g. looking at git diffs will always be cleared with self. -
there's not syntax highlighting there.
What I don't understand is why can't this be an option. There are two camps,
each advocating either preferences and each camp is quite vocal about it. Why
not let the user decide? Hence my proposal to make it an optional warning.
Since the self. usage is not mandatory, yet is supported (no one is stopping
anyone from using it), I don't see a reason why there shouldn't be a compiler
option to help people who'd like to use this to enforce it; which would make
both camps happy.
When you take a look at all the LLVM warnings options, there are things people
usually don't have enabled, but advanced users or users who prefer safer code,
can enable them. E.g. -Wfour-char-constants for warning about four-char
OSTypes, etc. (just go through them in Xcode build settings).
I don't see this option harming anyone - it'd be only helping people wanting to
have safer codebase.
Krystof
> On May 19, 2016, at 9:15 PM, Michael Peternell via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> Well, SE-0009 is not related to shadowing, is it? I think it is something
> completely different.
>
> The problem that SE-0009 tries to solve is that when looking at a line in
> isolation, like
>
> print(foo)
>
> there is no way to tell wether foo is an iVar, a local var or a parameter.
> This can happen if you don't remember the names of all iVars of a class. A
> warning on shadowing will not help here at all. I think shadowing is not bad,
> and if someone wants to disallow shadowing, he should make another proposal.
> After all, if I add another iVar to a class, I want it to still compile. With
> shadowing disallowed, I may give an iVar the same name as the local variable
> in some of the methods.
>
> Regarding the original SE-0009, I think it is better to use syntax
> highlighting for this. Xcode already does it well: local vars are black,
> other vars have some color (with the "Default" syntax highlighting theme).
>
> I know not everyone is using Xcode. But anyways, coding without an IDE is
> always painful if the program you write has more than 500 lines. And for any
> IDE that has autocompletion and something like the "Jump to symbol" feature
> of Xcode, implementing syntax highlighting right is not that hard. Omitting
> "self" is convenient, and the problems arising from it are not so bad that
> "self" should be made mandatory IMO.
>
> -Michael
>
>> Am 19.05.2016 um 20:12 schrieb Vladimir.S via swift-evolution
>> <swift-evolution@swift.org>:
>>
>> Oh, in this case IMO warning for 'self.' will never be introduced, it's
>> clear. And as I understand, no support in community for warning for
>> shadowing. OK, so as I understand, the only solution here - tools like
>> SwiftLint and plugins to xcode.
>>
>> Btw, regarding 'similar to the override keyword', do you mean something like
>> this:
>>
>> class A {
>> public var x = 10
>>
>> func f() {
>> override var x = 100
>>
>> var value: Int? = 1
>> if override let value = value {..}
>> }
>> }
>>
>> ?
>>
>> On 19.05.2016 20:58, David Waite wrote:
>>> I believe the Swift Team has previously stated they do not want opt-in
>>> warnings defining alternate swift ‘grammars’. I don’t believe there are
>>> any existing -W flags for the compiler, for instance.
>>>
>>> If there is shadowing warning added, I’m of the opinion it should work
>>> similar to the override keyword.
>>>
>>> -DW
>>>
>>>> On May 19, 2016, at 11:28 AM, Vladimir.S via swift-evolution
>>>> <swift-evolution@swift.org> wrote:
>>>>
>>>> On 18.05.2016 22:43, Krystof Vasa wrote:
>>>>> I agree that shadowing variables is not a good idea, but I stand by
>>>>> my point that it's potentially dangerous and error-prone to allow
>>>>> accessing instance variables without `self`.
>>>>
>>>> Could we all agree that we need these options: 1. option to turn on
>>>> warnings on accessing instance variables without `self` 2. option to
>>>> turn on warnings on shadowing And that by default, none of that
>>>> options should be enabled. ?
>>>> _______________________________________________ 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
>
> _______________________________________________
> 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
