<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Mar 22, 2017, at 11:27 AM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">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<span class="Apple-converted-space"> </span></span><i class="" style="font-family: Helvetica; font-size: 12px; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">all</i><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""> of the magic in the key path types themselves. I think I would like that approach.</span></div></blockquote></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">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.</div><br class=""><div class="">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div class=""><div style="font-size: 12px; " class="">-- </div><div style="font-size: 12px; " class="">Brent Royal-Gordon</div><div style="font-size: 12px; " class="">Architechies</div></div></span>
</div>
<br class=""></body></html>