On Oct 7, 2015, at 17:44 , Rick Mann <email@hidden> wrote:
Well, the promise of the playground is fast prototyping. But the problem actually shows up in Xcode, too, since it's a crash in SourceKitService. Just typing away in Xcode makes it crash.
FWIW, my gut feeling about what mostly causes Source Kit to crash is nesting errors. For example, if you’re using generics, you need to use matched ‘< … >’ bracketing, which means of course that there are at least short intervals where you have an opening bracket but no closing bracket. If you’re inserting something into existing code, then this causes the overall nesting structure to shift suddenly to something that’s very, very wrong (since it “consumes” other bracketing that already exists), and the source code becomes so nonsensical to analysis that Source Kit and/or the compiler just give up.
In effect, the problem is that the compiler continues trying to make sense of the fubar'ed source long past the point where it should have given up. That’s a compiler error reporting/recovery defect, and it’s not that surprising in a fairly new compiler — deepening strategies for good error detection and reporting is a whole other phase of compiler development lifetime.
My point is that you’ll probably see more of such problems in playgrounds, because you’re prototyping and frequently changing basic structure like bracketing.
In my experience so far, generic angle brackets and braces in property implementations are the biggest cause of difficulty. Square brackets and parentheses perhaps not so much, maybe because the compiler uses a different syntax analysis algorithm for expressions, the context where these mostly occur. Braces in method implementations are probably easier because there’s the unique ‘func’ keyword to serve as absolute punctuation.
The other possible factor is that C-like languages necessarily have a distinct lexical phase (even if the compiler is clever enough to run it simultaneously with a syntax analysis phase). That is, in C there is a dumb analysis first, and one or more smart analyses afterward. Nesting errors are caught by the dumb analysis, which limits the secondary errors. Swift is probably more integrated in its approach, and therefore more vulnerable to meltdown.
This is all pure speculation, of course, but perhaps it may help to think of Swift as still climbing a pretty high mountain. If progress seems too slow, you can choose not to continue using it in earnest.
|