Good catch.
I think that would only affect poorly written code, and even then very rarely:
-
I have seen no style guide which recommends anything but no space before the colon and some whitespace after it (at least related to function parameters/arguments). That means the compiler could default to the same whitespace heuristic it currently uses to guess at prefix, postfix and infix operators, and then fall back to the opposite only if the fast path fails:
-
x: y
→ label: argument
-
x :y
→ argument :label
-
x:y
→ ??? → Try 1 first, since it is the only variant that was allowed ≤ Swift 5.
-
Given that labels are normally adposition‐like phrases and variable names are generally noun‐like phrases, only one of the two arrangements is likely to ever actually match declared identifiers. In the extremely rare case that it is still ambiguous, an extra colon could be allowed in order to enclose the argument from both sides even when there is no label to make it ultra‐explicit: (w, : x :y, z)
and (w, x: y :, z)
would be the two unambiguous versions of (w, x:y, z)
. Alternatively an underscore could be required too to blank out the absent label: (w, _: x :y, z)
or (w, x: y :_, z)
.
Your spaced version is a reasonable alternative, I just worry that the visual cue the colon provides would be lost in situations (like Turkish) where almost everything only has postposition labels.
Given:
typealias Dizi = Array
extension Dizi {
typealias Dizin = Index
typealias Öğe = Element
}
var dizi = ["a", "b", "c"]
Which is better?
extension Dizi {
func (_ dizin: Dizin e, _ yeniÖğe: Öğe)eklemek {
insert(yeniÖğe, at: dizin)
}
}
dizi.(3 e, "ç")eklemek
vs
extension Dizi {
func (_ dizin: Dizin :e, _ yeniÖğe: Öğe)eklemek {
insert(yeniÖğe, at: dizin)
}
}
dizi.(3 :e, "ç")eklemek // This is an exact reversal of the English.
At the same time, leading colons as a punctuation symbol do not have a precedent in any human language I am aware of, so a more logical replacement would certainly be welcome. A hyphen might be a suggestion, since many postpositions are actually suffixes:
extension Dizi {
func (_ dizin: Dizin ‐e, _ yeniÖğe: Öğe)eklemek {
insert(yeniÖğe, at: dizin)
}
}
dizi.(3 ‐e, "ç")eklemek
A hyphen (U+2010) is not valid yet anywhere in the grammar, so it would be very viable. The downside is it would be the first time Swift required a character from outside ASCII and it would be visually mistakable for the minus operator, at least without syntax highlighting.
P.S. In typing these last examples I noticed that there can already be whitespace‐juxtaposed, collapsable tokens in the declaration when the label is different from the name, though it might not matter, since the type has to intervene before the trailing section:
func doSomething(object anObject: AnyObject) {}
(Interpreting those two identifiers with SwiftSyntax
is currently a nuisance. The compiler only gives you firstName
and secondName
and have to sort out labels vs names yourself.)