In general, using a list of identifiers that the compiler wants to easily recognize as a list of keywords to highlight is going to lead to bad results. The compiler sometimes has to add special cases for certain declarations, e.g. to maintain source compatibility; that doesn’t mean you should highlight them differently in an editor.
In particular, many of those identifiers are actually attribute names. You should probably have a rule for highlighting after an @ that covers all attributes without having to recognize specific attribute names.
i don’t know the full story of your app’s architecture, but unless you have major constraints preventing you from depending on SwiftSyntax/LSP i really, strongly, suggest you work on a way to get SwiftSyntax running on the target platform, because i am skeptical that an approach that involving detecting special substrings in source text is going to be successful.
I think it will cover the main 95% of cases easily, especially if to add some heuristic like highlighting after @, # and //, and within "strings" or /* comments */. It would be quite useful even if it doesn't cover all 100% of cases.
I'd make contextual keywords (that could result in false positives) of a different colour compared to "always" keywords, e.g. less prominent.
I also feel that recognizing all keyword, including internal ones, is non-goal for a syntax highlighting engine. I would focus on making sure nested structure and delimiters are parsed correctly in all circumstances instead.
All underscored keywords are internal. The contextual keyword yield is also technically internal, but _read and _modify are so useful that all three have leaked out into production code. I think that's all of them, unless there's some ancient internal keyword nobody uses anymore floating around without any underscores.
there is also @_spi, @_exported, and the __owned, __shared, and __consuming keywords. they are technically internal but the latter three keywords are so common it is hard to read certain signatures if they are not highlighted.
today, in new code, __owned and __consuming are mostly used to work around compiler bugs, and i imagine they will die out soon. i don’t see __shared going away any time soon, as it’s quite a bit more challenging to substitute borrowing for it.
I was recently approached by someone who did not know Swift. But he abandoned the language just because of this discussion. Too many keywords. I found that short sighted and was unable to answer do to not enough knowledge about other languages. But however if somebody feels up to writing a comprehensive blog post about this subject it would help if it could be put on swift.org to point criticasters too? I would be happy to help in the writing/reviewing. Anybody has ideas for this?
Some languages make a point out of having few reserved keywords, to the point where they instead overload keywords based on context. static means several different things in C/C++ depending on where they're used.
Go uses for for all loop constructs whereas Swift has for, while and repeat. That means that you can discern what kind of loop a Swift loop is at a glance whereas a Go loop requires looking closely at the full signature of for to see if it is an iterating one, a while true or until true one.
Go even goes as far as using comments to control compilation and linking, just to avoid introducing more keywords.
Swift also has looping constructs that are defined as methods, such as .forEach. Those are not classified as keywords but they exist all the same, and I wouldn't call a language where if and else are method less complex than one where they are keywords — unless your goal is to construct a syntax highlighter.