> On Mar 22, 2017, at 11:27 AM, Matthew Johnson via swift-evolution > <[email protected]> wrote: > > One option would be to include `get` and `set` methods on the key path types. > That would allow us to write the subscripts in the standard library (if it > is allowed to extend Any) and keep all of the magic in the key path types > themselves. I think I would like that approach.
This is not a good option. Although we Swift users may write `get` and `set` accessors, the real primitives in Swift are `get` and `materializeForSet`, which is basically "return a pointer that can be modified until another call is made which finalizes the set". `materializeForSet`'s call sequence is too low-level to be written manually; without adding other features to the language, we're basically left with either calling a method that calls a closure with an `inout` parameter, or using a subscript. The ownership manifesto includes a generator feature which could, some day, make it possible to write a method wrapping `materializeForSet`. But subscripts allow us to do this today, and it's *perfectly* natural to think of key paths as being a subscript; subscripts are for accessing values inside an instance, and a key path addresses a value inside an instance, too. 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. I can't find it now, but I once read someone state that this is part of what happened to C++: Every time someone proposed a new feature, people were worried that they would use it by accident, so they insisted that it have an unmistakable, obvious syntax so you would know you were using it. The result is that now, almost every syntax in C++ is shouting at you that you're using feature X, Y, or Z, and you can't hear your own code over the din. 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. -- Brent Royal-Gordon Architechies
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
