Where can I get the full list of Swift keywords?

[John_McCall]

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.

[taylorswift]

@dima_kozhinov

Yes, it is a desktop app, not written in Swift, that should be able to do syntax highlighting without installing Swift.

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.

[tera]

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.

[Slava_Pestov]

@John_McCall

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 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.

[dima_kozhinov (Dmitry Kozhinov)]

@Slava_Pestov

recognizing all keyword, including internal ones, is non-goal

Indeed. But how do I know that a keyword is "internal"? Do you mean those keywords that start with the _ character?

[Nobody1707]

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.

[taylorswift]

@Nobody1707

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.