[swift-evolution] Annotation of Warnings/Errors

[Saagar Jha]

There's nothing wrong with fix-its and error messages, and indeed they can
be quite helpful-the issue is that sometimes they show up when they really
shouldn't, like in the middle of typing a line. Novices will then often
stop and see what it's trying to say (wouldn't you trust a tool if it tells
you something's wrong, especially if you're not acquainted with it?), and
the advice it gives is often irrelevant since the compiler doesn't have a
full understanding of what's going on. This simply suppresses the error
until the programmer is done typing.

Sent from my iPhone


> On Jan 25, 2017, at 23:31, Rien via swift-evolution <
swift-evolution at swift.org> wrote:
>
> OTOH, looking at fixit and error messages can also aid in understanding
Swift better.
> Seeing what happens when it happens is something I find quite useful.
>
> Not that I have anything against the proposal, but I do wonder if that is
the best usage of available resources.
>
> A BIG OT warning:
>
> If people are so easily put off, they probably are not very suited to
being a programmer/sw-engineer. It might be good for them to drop out asap
so they can pursue something more fitting to their personality… I have met
a lot of people that would have been better off not to get into
programming. It would have been better for them and for the projects they
worked on.
>
> Regards,
> Rien
>
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl
>
>
>
>
>
>> On 26 Jan 2017, at 00:46, 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
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-- 
-Saagar Jha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170126/9eb1b0ba/attachment.html>