[swift-evolution] [Pitch] Retiring `where` from for-in loops

[Jo Albright]

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