-1. I'm against strongly this proposal for several reasons:
-
It makes basic tooling harder to build, because the simple notion of "what's an identifier that can name things in Swift" is no longer simple. GitHub syntax-highlighting
varin thevar `some var` = 0example from the proposal is one example. If you double-click on either of the works within the back ticks, there is no editor or tool out there that will properly select the whole identifier. And because back-ticks aren't a balanced set of delimiters, you literally have to scan to the beginning of the source line to determine what is the "identifier". -
Putting unstructured text within the back-ticks cuts off any future evolution that might put more structured information within back-ticks. For example, providing the ability to name zero-parameter functions or to name the accessors of properties as a function entity, e.g.,
x.`getter:property`or ``x.zeroParameterMethod(), which cannot be named today. Similarly for subscripts. Some of this was discussed a long time ago, but still seems like a good direction for the language. We shouldn't cut off future directions for a small win.
No. There are two motivating use cases as far as I can tell:
-
Having spaces in the names of test functions. This is a small convenience, and we can probably improve this case in another way.
-
Being able to reference an operator by name, e.g.,
Int.+`. This one could be addressed by allowingInt.+in the grammar. It's more discoverable and should be straightforward.Doug