I'd quibble with you on the detailed design, but personally I think the general idea is quite wonderful.
Quibble: I don't particularly think different-scope and different-function are in practice usefully distinct. And I think that for maximum elegance we could parallel the supported access levels: immediate (actually, is this one _strictly_ necessary? seems next-line is sufficiently immediate feedback), different-line, different-scope, different-file. But overall, wonderful. On Wed, Jan 25, 2017 at 17:46 Jonathan Hull via swift-evolution < swift-evolution@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution