[swift-evolution] Smart KeyPaths
Karim Nassar
karim at karimnassar.com
Thu Mar 23 08:48:59 CDT 2017
> I guess I just don't understand why people seem so eager to change this syntax. The biggest complaint seems to be that it's too lightweight and natural; they're worried they might not realize they're using this big, scary new feature. But this feature simply *isn't* big and scary! It's new right now, but in a few years it's going to feel very natural.
>
> […]
>
> Key paths are about as nonthreatening as a syntax can be. They overload some things, but the type checker will catch most overloading mistakes. Other than that, there's just no justification for the level of anxiety people seem to have. They don't break type safety, they don't involve unusual or non-obvious control flow, they don't trap, and they can be explained in a couple of sentences. If ever there was a candidate for a lightweight syntax, this is it.
>
> As the protest sign says: "I want YOU to stop being afraid". I have yet to be convinced that this feature is too dangerous or mistake-prone to allow the simple, natural syntax the authors propose. If I'm wrong, then by all means show me I'm wrong, but I just don't see it.
I don’t have a strong opinion on the sigil question one way or another, but I’m not sure it’s fair to categorize the sigil proponents as being afraid of the feature. I do find the argument that some kind of sigil to clarify the construction-site of a KeyPath somewhat compelling.
KeyPath declarations as described in the proposal are fairly unique in that they have all the appearance of accessing a property value on a type, but are in fact a mechanism for “creating” (referencing?) a type entirely different from their face-value. That is: a KeyPath shares most of its spelling with the value that it points to, and absent knowledge of the programmer’s *intent* it’s not immediately obvious whether code is accessing a value or creating a KeyPath. They are references to a named member of a type which are derived by their name.
IMHO, it’s not *that* unreasonable to want a spelling variation to call attention to this difference.
In any case, as I said, I’m not strongly opinionated on this matter, but perhaps it *is* worth considering some sigil we could apply to both KeyPath and function assignments to clarify both sites in the same way.
—Karim
More information about the swift-evolution
mailing list