Re: [swift-evolution] Proposal SE-0009 Reconsideration

As another colorblind developer, I have trouble paying attention to the syntax highlighting. I didn’t even notice that member variables were colored until someone mentioned it on this list. > On May 23, 2016, at 9:43 AM, Jeff Kelley via swift-evolution > wrote: > > As a colorblind developer,

Re: [swift-evolution] Proposal SE-0009 Reconsideration

While not as nice, Vladimir’s colon suggestion could work. :g() Reminds a bit of C++ but not bad. > On May 26, 2016, at 2:05 PM, Brent Royal-Gordon > wrote: > >> * Already very similar notation for enums where you leave off the entity >> name when it can be implied. > > That's the problem. L

Re: [swift-evolution] Proposal SE-0009 Reconsideration

> * Already very similar notation for enums where you leave off the entity name > when it can be implied. That's the problem. Leading dot already means something—it means "look up a static member of the type we're expecting here". (That's what you're actually doing when you access an "enum case

Re: [swift-evolution] Proposal SE-0009 Reconsideration

IMO nice idea, but I see that this could be confused with using enum values: enum E { case one case two static func foo(e: E) {} } struct S { var one = 100 ... func f() { E.foo(.one) print(one) // ? print(.one) someFunc(.something) // is it enum

Re: [swift-evolution] Proposal SE-0009 Reconsideration

Since this keeps coming up, it seems that something would be good here. Perhaps this has been explored before but why can’t we just use dot without the word “self", to indicate self? class DotIsSelf { func p() -> String { return "self p" } func g() { print(.p())

Re: [swift-evolution] Proposal SE-0009 Reconsideration

On Mon, May 23, 2016 at 12:26 PM, David Sweeris via swift-evolution wrote: > Dunno about other IDEs, but Xcode's syntax highlighting can change the size, > typeface (bold, italic, etc), and even the font. You can make instance > variables show up as 24pt comic sans, if you want. You can’t do pol

Re: [swift-evolution] Proposal SE-0009 Reconsideration

On 23.05.2016 21:41, Charles Srstka via swift-evolution wrote: Plus, I might end up having to use a different source editor sometimes, particularly when I’m doing a large refactor and Xcode is stuck in its “SourceKitService crash every time two characters are typed” thing. I’d really rather have

Re: [swift-evolution] Proposal SE-0009 Reconsideration

As another colorblind developer, this kind of is an issue. While I *can* discern colors, the only one that sticks out strongly is blue. If you’ve got reds, greens, browns, or oranges, my experience will be on a continuum from “I think that’s red?” in the best case, “I can figure this out if I a

Re: [swift-evolution] Proposal SE-0009 Reconsideration

> On May 23, 2016, at 7:26 PM, David Sweeris wrote: > > > On May 23, 2016, at 11:24, Krystof Vasa via swift-evolution > wrote: > >>> The problem can also be easily mitigated by having the IDE use a different >>> color to display a variable based on where it was defined (eclipse come to >>

Re: [swift-evolution] Proposal SE-0009 Reconsideration

On May 23, 2016, at 11:24, Krystof Vasa via swift-evolution wrote: >> The problem can also be easily mitigated by having the IDE use a different >> color to display a variable based on where it was defined (eclipse come to >> mind as an example). This is something the brain naturally notices

Re: [swift-evolution] Proposal SE-0009 Reconsideration

> On May 23, 2016, at 6:43 PM, Jeff Kelley wrote: > > As a colorblind developer, this isn’t really an issue. The vast majority of > colorblind people can discern colors. As long as the IDE allows you to > customize which colors it displays, you can find a palette that will work > with your e

Re: [swift-evolution] Proposal SE-0009 Reconsideration

The IDE will speak the scope name... :) On May 23, 2016, at 6:24 PM, Krystof Vasa wrote: >> The problem can also be easily mitigated by having the IDE use a different >> color to display a variable based on where it was defined (eclipse come to >> mind as an example). This is something the bra

Re: [swift-evolution] Proposal SE-0009 Reconsideration

As a colorblind developer, this isn’t really an issue. The vast majority of colorblind people can discern colors. As long as the IDE allows you to customize which colors it displays, you can find a palette that will work with your eyes (for my type of colorblindness, for instance, I have difficu

Re: [swift-evolution] Proposal SE-0009 Reconsideration

> The problem can also be easily mitigated by having the IDE use a different > color to display a variable based on where it was defined (eclipse come to > mind as an example). This is something the brain naturally notices without > paying any conscious attention. Tell that to the colorblind :)

Re: [swift-evolution] Proposal SE-0009 Reconsideration

Sent from my iPad > On May 22, 2016, at 11:33 AM, Pyry Jahkola via swift-evolution > wrote: > > >> On 22 May 2016, David Hart wrote: >> >> If the design team is very serious about not integrating optional warnings, >> then I don’t think it is a huge bother to implement think in linters lik

Re: [swift-evolution] Proposal SE-0009 Reconsideration

> On 22 May 2016, David Hart wrote: > > If the design team is very serious about not integrating optional warnings, > then I don’t think it is a huge bother to implement think in linters like > SwiftLint is doing. I'm fine with the way SE-0009 was decided but I think the review left one consi

Re: [swift-evolution] Proposal SE-0009 Reconsideration

> On 22 May 2016, at 11:08, Charlie Monroe via swift-evolution > wrote: > > My main argument is that Swift is aspiring to be more than a language used > for "apps on AppStore". As I've mentioned in the proposal, sensitive projects > can't afford this class of bugs, since they are simple to ma

Re: [swift-evolution] Proposal SE-0009 Reconsideration

> On May 22, 2016, at 3:22 AM, Erica Sadun via swift-evolution > wrote: > > >> On May 21, 2016, at 5:30 AM, Charlie Monroe via swift-evolution >> wrote: >> >> I have created a proposal for making the self. optional warning. It can be >> viewed here: >> >> https://github.com/charlieMonroe

Re: [swift-evolution] Proposal SE-0009 Reconsideration

> This is why I was suggesting earlier in this thread to focus on warnings when > variables and methods are being shadowed, and now to declare in code that a > name is meant to shadow another name. I suspect that (with sufficient > bikeshedding) this would meet the bar for the swift always-on wa

Re: [swift-evolution] Proposal SE-0009 Reconsideration

> I suspect the only issue is that there are lots of things that people would > want to have as optional warnings, and it might be hard to justify why this > optional warning is more important than other optional warnings all of which > would benefit the user. In previous conversations, I believ

Re: [swift-evolution] Proposal SE-0009 Reconsideration

On 22.05.2016 4:49, David Waite via swift-evolution wrote: This is why I was suggesting earlier in this thread to focus on warnings when variables and methods are being shadowed, and now to declare in code that a name is meant to shadow another name. I suspect that (with sufficient bikeshedding)

Re: [swift-evolution] Proposal SE-0009 Reconsideration

> On May 21, 2016, at 7:22 PM, Erica Sadun via swift-evolution > wrote: > > >> On May 21, 2016, at 5:30 AM, Charlie Monroe via swift-evolution >> wrote: >> >> I have created a proposal for making the self. optional warning. It can be >> viewed here: >> >> https://github.com/charlieMonroe/s

Re: [swift-evolution] Proposal SE-0009 Reconsideration

> On May 21, 2016, at 5:30 AM, Charlie Monroe via swift-evolution > wrote: > > I have created a proposal for making the self. optional warning. It can be > viewed here: > > https://github.com/charlieMonroe/swift-evolution/blob/master/proposals/-optional-warning-for-explicit-self.md > > D

Re: [swift-evolution] Proposal SE-0009 Reconsideration

I have created a proposal for making the self. optional warning. It can be viewed here: https://github.com/charlieMonroe/swift-evolution/blob/master/proposals/-optional-warning-for-explicit-self.md Does anyone see a downside to this solution, having it an optional warning? > On May 20, 201

Re: [swift-evolution] Proposal SE-0009 Reconsideration

Agreed, this is a topic that needs to be properly solved. Sent from my iPhone > On 20 May 2016, at 05:34, Krystof Vasa via swift-evolution > wrote: > > From the rejection rationale: > >> * Individuals or teams that feel that explicit “self.” is beneficial for >> their own code bases can enfo

Re: [swift-evolution] Proposal SE-0009 Reconsideration

From the rejection rationale: > * Individuals or teams that feel that explicit “self.” is beneficial for > their own code bases can enforce such a coding convention via tooling with > the status quo. If this proposal were accepted, those opposed to the proposal > would effectively have no recou

Re: [swift-evolution] Proposal SE-0009 Reconsideration

Hi Brent and Krystof, The proposal brought a lot of interesting discussions, but in the end, I think the right choice was made. It fits the Swift philosophy and rational, both in terms of the decision concerning the self. and concerning not having a warning. It took some time for me to try and

Re: [swift-evolution] Proposal SE-0009 Reconsideration

> 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. > When you take a look at all the LLVM warnings options, the

Re: [swift-evolution] Proposal SE-0009 Reconsideration

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 prefer

Re: [swift-evolution] Proposal SE-0009 Reconsideration

> On May 19, 2016, at 2:15 PM, Michael Peternell via swift-evolution > wrote: > > 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. Or whether print() is

Re: [swift-evolution] Proposal SE-0009 Reconsideration

Is the status quo in this honey moon phase better? Sent from my iPhone > On 19 May 2016, at 19:12, Sean Heber via swift-evolution > wrote: > > I think it is too easy to just add warnings for warts and call it a day. > These problems, IMO, should be addressed somehow eventually - but not with

Re: [swift-evolution] Proposal SE-0009 Reconsideration

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 i

Re: [swift-evolution] Proposal SE-0009 Reconsideration

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', d

Re: [swift-evolution] Proposal SE-0009 Reconsideration

I think it is too easy to just add warnings for warts and call it a day. These problems, IMO, should be addressed somehow eventually - but not with a warning. Either Swift decides these situations are errors and refuses to enable them at all, or the constructs involved should be carefully recons

Re: [swift-evolution] Proposal SE-0009 Reconsideration

And... is this all OK? No one think this is a broken design? So, in addition to the example with getInt() (when no method declaration exists in protocol itself, but just in extension and in type), we have this: protocol A { func f() func x() } extension A { func x() {print("a-x")}

Re: [swift-evolution] Proposal SE-0009 Reconsideration

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 key

Re: [swift-evolution] Proposal SE-0009 Reconsideration

Oh, cool! This is exactly the same code I was asking the community to comment out if this is wanted/expected behavior. Unfortunately no reply was given. This is why I suggested a warning if type's method has the same name as such protocol extension method in my current thread "[Pitch] Requiring

Re: [swift-evolution] Proposal SE-0009 Reconsideration

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 warning

Re: [swift-evolution] Proposal SE-0009 Reconsideration

I'd prefer to raise warning for any shadowing, and so, in case of `if let value = value` we'll have a warning: in discussions about 'if let! value' construction proposal there was many opinions that 'if let v = v' is a bad style and you should avoid to do this and improve your code to not do th

Re: [swift-evolution] Proposal SE-0009 Reconsideration

Hi Vladimir.S, Goffredo already described it well. That was exactly what I was referring to. -Michael > Am 19.05.2016 um 14:51 schrieb Goffredo Marocchi : > > In addition to what has already been posted: > > https://nomothetis.svbtle.com/the-ghost-of-swift-bugs-future > > https://medium.com/i

Re: [swift-evolution] Proposal SE-0009 Reconsideration

Hello Jeremy, It seems it is a little bit more complex than this: http://allblue.me/swift/2016/01/23/swift-method-dispatch-with-protocol-extension-protocol-extension-and-subclass/ [image: diagram] - IF the inferred type of a variable is the protocol: - IF the method is in a class conform

Re: [swift-evolution] Proposal SE-0009 Reconsideration

> On 19 May 2016, at 13:30, Krystof Vasa via swift-evolution > wrote: > > See this example that demonstrates how it's pretty much unusable (IMHO), > since whenever you refer to the instance as to the protocol, the default > implementation gets invoked: > > protocol MyProtocol { } > > extens

Re: [swift-evolution] Proposal SE-0009 Reconsideration

In addition to what has already been posted: https://nomothetis.svbtle.com/the-ghost-of-swift-bugs-future https://medium.com/ios-os-x-development/swift-protocol-extension-method-dispatch-6a6bf270ba94#.14j0qq1i3 (even more complete summary of previous research in this issue) http://allblue.me/swi

Re: [swift-evolution] Proposal SE-0009 Reconsideration

See this example that demonstrates how it's pretty much unusable (IMHO), since whenever you refer to the instance as to the protocol, the default implementation gets invoked: protocol MyProtocol { } extension MyProtocol { func getInt() -> Int { return 0 } } clas

Re: [swift-evolution] Proposal SE-0009 Reconsideration

On 19.05.2016 0:01, Michael Peternell wrote: Not Fun To Debug bits (similar to the dispatching rules of protocol extensions default methods). There are dispatching rules of protocol extension default methods? I thought the methods are selected randomly... just kidding - [offtopic] Could you pl

Re: [swift-evolution] Proposal SE-0009 Reconsideration

On 19.05.2016 0:09, Krystof Vasa via swift-evolution wrote: Yes, of course. But if you mark shadowing as error/warning, you need to update dozens if not hundreds of places in your projects since most default argument names in UITableViewController shadow the tableView instance variable. I belie

Re: [swift-evolution] Proposal SE-0009 Reconsideration

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 sy

Re: [swift-evolution] Proposal SE-0009 Reconsideration

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

Re: [swift-evolution] Proposal SE-0009 Reconsideration

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

Re: [swift-evolution] Proposal SE-0009 Reconsideration

Perhaps a better approach to the shadow variables problem is to enable the objc compiler flag -Wshadow to be available in Swift. In the same way a "requiring self" compiler flag should help enforce self on the programer by always showing a warning when the flag is on. > On May 18, 2016,

Re: [swift-evolution] Proposal SE-0009 Reconsideration

>> See my example with the tableView and the UITableViewDelegate on >> UITableViewController. `if let x = x` isn't the usual case. The usual case >> is that you have e.g. tableView instance on the class and a method that >> takes a tableView parameter. > That would be shadowing. Yes, of course.

Re: [swift-evolution] Proposal SE-0009 Reconsideration

> Am 18.05.2016 um 21:53 schrieb Goffredo Marocchi via swift-evolution > : > > The code you pasted really ought to print a warning out (allowing variable > shadowing without even a warning can lead to annoying bugs), a generation of > Swift developers will be trained by relying on the Swift c

Re: [swift-evolution] Proposal SE-0009 Reconsideration

> On May 18, 2016, at 1:43 PM, Krystof Vasa wrote: > > See my example with the tableView and the UITableViewDelegate on > UITableViewController. `if let x = x` isn't the usual case. The usual case is > that you have e.g. tableView instance on the class and a method that takes a > tableView pa

Re: [swift-evolution] Proposal SE-0009 Reconsideration

The code you pasted really ought to print a warning out (allowing variable shadowing without even a warning can lead to annoying bugs), a generation of Swift developers will be trained by relying on the Swift compiler to make their code automagically safe and this is another one of those Not Fu

Re: [swift-evolution] Proposal SE-0009 Reconsideration

See my example with the tableView and the UITableViewDelegate on UITableViewController. `if let x = x` isn't the usual case. The usual case is that you have e.g. tableView instance on the class and a method that takes a tableView parameter. Then you change the method signature not to include the

Re: [swift-evolution] Proposal SE-0009 Reconsideration

I always thought that requiring self everywhere was a red herring, and that what was really needed was clearer use of shadowing. But “if let x = x” is a case of the developer asking for shadowing. So either: - shadowing only causes warnings in some places and is allowed in others (and has a way

Re: [swift-evolution] Proposal SE-0009 Reconsideration

Sure, but that assumes that you know where the issue is. Since the app compiles and works fine, except for various glitches, you need to debug this (takes time). This is not preventing an issue that shouldn't happen in the first place. > On May 18, 2016, at 8:20 PM, Karl via swift-evolution >

Re: [swift-evolution] Proposal SE-0009 Reconsideration

And that works about 30% of the time, if you’re being generous. Charles > On May 18, 2016, at 1:20 PM, Karl via swift-evolution > wrote: > > Since you’re using OSX - CMD + click, jumps to definition. > >> On 18 May 2016, at 07:09, Krystof Vasa via swift-evolution >> wrote: >> >> Hi there,

Re: [swift-evolution] Proposal SE-0009 Reconsideration

Since you’re using OSX - CMD + click, jumps to definition. > On 18 May 2016, at 07:09, Krystof Vasa via swift-evolution > wrote: > > 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 Cambr

Re: [swift-evolution] Proposal SE-0009 Reconsideration

Hm.. can't check right now.. But can't we change `tableView` parameter name as it is internal name for parameter func tableView(*theTableView*: UITableView, didSelectRowAtIndexPath indexPath: NSIndexPath) { } In any case, I think the problem with shadowing exists and IMO Swift will be better

Re: [swift-evolution] Proposal SE-0009 Reconsideration

For this, maybe. But consider e.g. UITableViewDelegate methods. They have a "tableView" variable within the method parameters. When you implement this on UITableViewController, you get automatically a shadowed variable: class MyController: UITableViewController { func tableView(tableVi

Re: [swift-evolution] Proposal SE-0009 Reconsideration

Fully support your opinion. +1 for warning option. Also, I believe we need a warning (not error as suggested by @Sean in reply to this thread) when type's property shadowed with local variable. Or do we *really* feel that this code don't require at least a warning ?? : class A { var x = 10

Re: [swift-evolution] Proposal SE-0009 Reconsideration

There's shadowing and shadowing. With instance variables, making this an error isn't a great idea. This will lead to people using "localTableView" instead of just "tableView" which IMHO leads to a code that's not easily readable. In 90% of cases, the issue is that you use something very generic

Re: [swift-evolution] Proposal SE-0009 Reconsideration

I’ve been wondering if shadowing variable names should just be an error. I know that it’s a very common pattern when unwrapping such as: if let thing = thing {} But that not only looks ugly, there’s often better ways to solve this and using different names there would also likely improve clarit

[swift-evolution] Proposal SE-0009 Reconsideration

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