<div dir="ltr">This sounds wonderful. It’s extremely common, in my experience with junior developers, for them to blindly accept Xcode’s suggestions—and why wouldn’t they? Delaying the display would certainly be a benefit for everyone, but especially people who are just learning Swift.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div style="font-family:Helvetica"><br></div><div style="font-family:Helvetica">Jeff Kelley</div><div style="font-family:Helvetica"><br></div><div style="font-family:Helvetica"><a href="mailto:SlaunchaMan@gmail.com" style="color:rgb(17,85,204)" target="_blank">SlaunchaMan@gmail.com</a> | <a href="https://twitter.com/SlaunchaMan" style="color:rgb(17,85,204)" target="_blank">@SlaunchaMan</a> | <a href="http://jeffkelley.org/" style="color:rgb(17,85,204)" target="_blank">jeffkelley.org</a></div></div></div></div>
<br><div class="gmail_quote">On Wed, Jan 25, 2017 at 6:46 PM, Jonathan Hull via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">One of the biggest issues that I saw while teaching Swift to newbies (most had not programmed before) is confusion based on the early warnings/errors that swift/xcode gives you as they type. What would happen is that they would type a variable, and it would say… “You haven’t used this variable” and so they would just click the fixit because they trust the compiler more than they trust themselves. This would lead to a point where they were very confused because some of the code was code they had thought through, and some of it was changed by random fixits in ways they didn’t understand… and so it would lead to more errors/fixits until they had errors which couldn’t be fixed.<br>
<br>
By the end of the semester they had learned to ignore the warnings until they were finished, but it took a couple of months to get there, and was a big deterrent to new users… (Also, learning to ignore warnings ignorer to use a system seems like an anti-pattern)<br>
<br>
I have a good friend who is an expert perl programmer who tried Swift and eventually gave up because he couldn’t figure out which errors to ignore (and which might just disappear a minute later) and which he needed to pay attention to. He was overwhelmed by the sheer number, and they didn’t seem trustworthy to him (“Swift is full of lies!” he would say of the warnings… which is a mantra I find myself parroting when I get those appearing/disappearing errors).<br>
<br>
<br>
To fix this, I propose adding a way to annotate warnings/errors to say how immediate they need to be:<br>
• Immediate - This error should always be shown<br>
• DifferentLine - This error should only be shown once the cursor is on a different line<br>
• DifferentScope - This error should only be shown once the cursor is in a different scope from this line<br>
• DifferentFunction - This error should only be shown once the cursor is in a different function<br>
<br>
So the “You haven’t used this variable” warning would be marked .differentScope, meaning that it would only show up once you had clicked away from the scope. The reason for this is that while you are in the same scope, it is fairly likely that you are still going to use the variable… so the warning is premature. Once I have left the scope, it makes sense to warn me.<br>
<br>
Similarly, the “You need a return value” error would be marked .differentFunction because you are likely to add one while typing the function. But a type mismatch with the return value would either be .immediate or .differentLine because you have made an error that isn’t likely to be fixed with more typing on other lines.<br>
<br>
I think this will cut way down on the number of warnings/errors that need to be ignored, which should increase trust in the system overall.<br>
<br>
To be clear, I am only proposing adding the annotation to Swift (probably with a default of .differentLine). The compiler would not repress the warning/error itself… just vend it with a way to retrieve the annotation. IDE makers like Apple/Xcode would then be free to use that extra information in their UI if desired.<br>
<br>
Thanks,<br>
Jon<br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</blockquote></div><br></div>