[swift-evolution] Annotation of Warnings/Errors

[Jeff Kelley]

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.


Jeff Kelley

SlaunchaMan at gmail.com | @SlaunchaMan <https://twitter.com/SlaunchaMan> |
jeffkelley.org

On Wed, Jan 25, 2017 at 6:46 PM, Jonathan Hull via swift-evolution <
swift-evolution at swift.org> wrote:

> 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.
>
> 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)
>
> 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).
>
>
> To fix this, I propose adding a way to annotate warnings/errors to say how
> immediate they need to be:
> • Immediate - This error should always be shown
> • DifferentLine - This error should only be shown once the cursor is on a
> different line
> • DifferentScope - This error should only be shown once the cursor is in a
> different scope from this line
> • DifferentFunction - This error should only be shown once the cursor is
> in a different function
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Thanks,
> Jon
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170125/286bd5db/attachment.html>