> On 15 Jun 2016, at 03:43, Jo Albright <[email protected]> wrote: > > This is probably going to get lost in this massive chain. But I am going to > try to throw out a solution that I am not currently finding in this > conversation. > > There is a huge battle between removing and keeping keywords based on > understanding. In my opinion keywords have a tendency to create more > confusion than any other part of the language. We have a great tool in place > to help teach developers what API methods and variables are and how they are > to be used. Using “Quick Help” you can easily learn more about that > declaration that didn’t make sense. > > Currently we have a lot of keywords that could do different things… for > example “in” is used in for loops to and also used in closure syntax. This > can create confusion easily and at some point start a proposal such as this > one. Instead of removing confusing pieces of a language, what about teaching > others what the keywords do and how they should be used. If Quick Help was > built to inform of what the keyword was doing in its current context, the > developer could easily make sense of what is going on and choose to correctly > use the syntax the way it is supposed to be used. You could even build in > suggestions for other keywords that may have relevance. > > Another example would be “return”. When teaching I noticed a lot of new > developers didn’t understand that no lines of code would run after it, but > then would get confused that you had to pass values on the same line to > return a value. Having Quick Help to not only explain how return works but > also tell you what Type it is expecting (including Void) would be very > helpful in learning. > > Whether or not “where” gets removed from for loops. I would really love the > Apple team to think about extending Quick Help to work with other parts of > syntax like keywords. > > Imagine a new user trying to figure out what “import”, “guard”, “defer”, > “lazy”, etc mean. They have to google or look through docs… Quick Help could > instantly give them more information without leaving their code. > > Thanks, > Jo
This is a really fantastic idea! Actually a big issue with many keywords is that they’re often such common words that they’re very hard to search for without being given more context (which is in itself a skill, I’m still caught out searching for things that others find with very similar yet subtly different search terms). I wonder where the correct place to suggest this would be, as it will require some kind of documenting mechanism for keywords, as well as the means to expose it inside Xcode, so possibly an Xcode feature? Not sure, but I think it’s absolutely worth exploring! I doubt anyone will mind if it gets a thread here on swift-evolution in the mean, as like you say it runs the risk of being buried here in this thread. On which note I really do think the discussion on actually removing where has run its course as it’s just going back and forth with little to no change in arguments. I think it’s premature to remove where from for loops until after the removal of where from conditionals has actually gone through and been in the wild some time, as it may well affect how confusing (or not) it is on for loops, plus it’d be nice to spend some time exploring other options like Jo’s, and Brent/Erica’s moving of the keyword, changes and/or additions to the keywords and so-on, which have been comparatively forgotten. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
