Currently, identifier-head doesn't include decimal-digit but what if it's allowed to use when it's escaped with backtick?
Maybe it doesn't make much sense for identifier itself but how about enum-case-name? People often use underscore to overcome the restriction but why can't we allow it with backtick as below?
// currently not allowed
enum Accuracy {
case `500m`
case `1km`
}
set(accuracy: .1km)
I think this can be very convenient and really neat.
Since we can't write .1 to mean 0.1, I believe this isn't too confusing. What do you think?
I'm more inclined to prevent identifiers from starting with a digit.
It's true that we have a precedent with tuples, since they get numeric identifiers for each property place (e.g. (1, 2).0 and (1, 2).1), but that's the only exception to the rule.
Since my field of expertise is mathematics, I would love the ability to define custom infix operators between numeric literals and variables with a blank identifier, in order to write modules having:
// strawman syntax
infix func ``(lhs: IntegerLiteral, rhs: Int) -> Int {
return lhs as Int * rhs
}
let x = 10
let y = x^2 - 4x + 4 // 4x is 4 * x
infix func ``(lhs: FloatLiteral, rhs: Complex) -> Complex {
return lhs as Complex * rhs
}
let i: Complex = (0, 1)
let z = 3 + 2i // 2i is 2 * i, i.e. (0, 2)
With your suggestion in place, this wouldn't be potentially possible anymore (well.. it's not possible even now since there should be a way to disambiguate 0x2p5 which is 64 written in hexadecimal notation, but I won't let my hopes fade away that easily~).
Numeric identifiers could be spelled between backticks where required, so those shouldn't be problematic:
let `1` = 1
1 // refers to the integer literal
`1` // refers to the variable `1`
struct TupleLike<A, B> {
let `0`: A
let `1`: B
init(_ a: A, _ b: B) {
`0` = a // or self.0 = a
`1` = b // or self.1 = b
}
}
let tuple = TupleLike("one", "two")
tuple.0 // is "one"
tuple.1 // is "two"
this really doesn’t seem like a motivating argument against this pitch. multiplication should only be written one way, and in Swift, that way is with the * operator. allowing things like 2x to mean 2 * x just makes your code harder to understand.
Yeah, I do this too. If this pitch makes it through evolution (and I hope it does!), I don't think we'd need to "write the backticks every time", because we already don't have to:
class Multipleton {
static let `default` = Multipleton() // backticks required because "default" is a keyword
init() { ... }
}
let instance = Multipleton.default // no backticks required
let instance: Multipleton = .default // also acceptable
var `42` = Double.pi // this looks silly but
var `false` = true // this is allowed.
And I think HTTPStatus.404 and SFSymbols.10.circle are pretty neat.
The current "convention" of using underscore prefix is only because you can't do `404` is my understanding
If the only question is whether this feature is "really essential" or "merely nice-to-have", I think this idea may not have any chance, but I personally don't feel using underscore prefix to overcome the current restriction is really a great idea especially now Property Wrapper feature magically uses it.
