SE-0275: Allow more characters (like whitespaces and punctuations) for escaped identifiers

[Joe_Groff]

Proposal rejected

The review of SE-0275: Allow more characters (like whitespaces and punctuations) for escaped identifiers ran from January 13 through January 20. The core team has decided to reject this proposal. Community reaction was mixed, and many of the people both supporting and rejecting the idea had concerns about the breadth of the set of characters this allows. Allowing more characters in identifiers would also add complexity to tooling, including syntax highlighting, IDEs, and runtime reflection libraries, which would need to be able to recognize quoted identifiers, know when identifiers would need to be quoted for presentation purposes, and potentially need to implement more elaborate parsing and escaping rules to handle these generalized identifiers. In the core team's judgment, this added demand on tooling is not justified by the amount of utility provided by the proposal. Of the use cases that came up in the pitch, proposal, and review discussion:

• One proposed use was to allow test functions to have self-descriptive natural language names, as in func `test that two plus two equals four`() . The core team feels that this use case could be better handled by test library design that allowed strings to be associated with test cases, rather than try to encode that information entirely in symbol names.
• This feature could also be used to enable libraries to more directly encode domain-specific names that are not currently valid Swift identifiers, such as status codes which begin with numbers like HTTPStatus.`404`, naming conventions that use normally-reserved symbols like SFSymbols.`10.circle`, or names from other languages Swift may interoperate with that have different valid identifier character sets like Forth.`FM/MOD`. This use case is more in line with the original intent of the backtick identifier feature, which was to allow for interop with libraries from C/ObjC/C++ that use names that would normally be reserved in Swift. However, the core team would like to see more concrete work done on libraries that would benefit from this functionality, to better gauge whether it is really essential or merely nice-to-have, and whether allowing a more restricted character set could achieve the desired results with less tooling complexity burden.
• The proposal also offers the syntax Foo.`+` as a way to spell qualified references to operators. The core team believes this is an important gap in the language to fill. However, the backtick syntax in its current form is strongly associated with removing "magic" from keywords, and in association with operator tokens, there is a potential for confusion as to whether + is the same as the operator + or a regular identifier made to be named + . Furthermore, there are additional aspects of operator naming that need to be addressed in order to fully solve the problem; particularly, there would ideally be a way to disambiguate the prefix , postfix , and infix forms of an operator without relying on type context to do so. The core team thinks that the subject of operator references deserves a design exploration of its own, with its own pitch and proposal.

Thanks to @adellibovi for proposing and implementing this feature, and thanks to everybody who participated in the review!