With this proposal, all identifiers have two syntactic forms, only one of them being always parseable.
A bad side effect is that this proposal will break code generators, documentation generators, and other programs of this family.
A fix, for those generators, will be to escape all identifiers, just in case they could not be parsed raw.
// Welcome to the future
import `TheModule`
class `TheClass`: `TheProtocol` {
func `theFunc`() { ... }
func `when I told you escaping was useful`() { ... }
}
It reminds me of generated SQL (except that almost nobody reads SQL, when we read Swift all day long):
-- Say hello to double quotes, just in case
SELECT * FROM "player" WHERE "id" = 1
Let's take a practical example, starting with our own tooling: the Swift interface generator embedded in Xcode. It escapes `default
`, `self
`, and alike, but preserves other identifiers
without escaping them, for legibility. Thank you, this is a quality tool.
The Swift interface generator ships with a function which decides if an identifier should be escaped or not (returns true for default
, false for foobar
).
This function is currently simple (it only has to check for a known list of keywords).
This function will become complex.
It is likely that this function will not be easily available to third-party tooling. Those may just give up and escape everything. Or ship with a poor-man buggy implementation.
It is likely that this function will be slow, forcing performance-focused tools to, again, escape everything.
With this proposal, all Swift identifiers can mean something in other languages.
This gives a security consideration: as long as HTML documentation generators are not "fixed" for this change, we'll see funny code appear:
func `<script>alert("pwnd")</script>`() { ... }
I stop here, but I'd be happy if the authors of the pitch would consider all those unfortunate consequences with care :-) Do we want "fallacies developers think about Swift identifiers" web pages to flourish?