<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Lens are a term from functional programming theory (I think largely Haskell in particular?). I don't know much about it, but here's somewhere to start: <a href="https://www21.in.tum.de/teaching/fp/SS15/papers/17.pdf">https://www21.in.tum.de/teaching/fp/SS15/papers/17.pdf</a></div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">l8r</div><div id="AppleMailSignature">Sean<br><br>Sent from my iPad</div><div><br>On Jun 28, 2016, at 6:11 PM, Michael Peternell via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><span>Really?? Or we just have #set and #get and no lenses, and it's done for Swift 3?</span><br><span></span><br><span>I never heard of lenses (Google does not help here). Was this serious or were you joking? Unless you can explain why #set and #get without lenses would be bad... or maybe #set and #get *are* lenses, in which case I'm not sure what you were trying to say. Reflexion -> Reflection?</span><br><span></span><br><span>-Michael</span><br><span></span><br><blockquote type="cite"><span>Am 29.06.2016 um 00:55 schrieb David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>This looks like lenses. I think we need to wait until after Swift 3 to discuss it, and come up with a bigger design that ties to reflexion.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>On 28 Jun 2016, at 22:04, Michael Peternell via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>So you're proposing that `#set(aVariableName)` should translate to `{aVariableName=$0}`, right? Where aVariableName can be any valid lvalue like `self.users` or `users` or `vc.viewControllers`..</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>I think this would be a good extension to Swift. (`users.set` does not work BTW, because maybe the `users` object has a `set` property.. maybe I wanted to refer to the `set` property which also happens to refer to a closure value.)</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>`#set(aVariableName)` also feels consistent with the `#keyPath(aVariableName)` property and falls into a similar category. Maybe `#setter(aVariableName)` would be even more clear? Furthermore, I want to additionally propose to introduce `#get(aVariableName)` (or `#getter(aVariableName)`) too.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>-Michael</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Am 28.06.2016 um 20:18 schrieb Austin Feight via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Proposal:</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I propose adding setter methods to vars, which could look something like this: `ApiClient().fetchUsers().then(#set(users))`</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Initially I thought it should work like this: `ApiClient().fetchUsers().then(users.set)`</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>but to accomplish a line of code that flows grammatically, I believe putting "set" where it would naturally fall if the code was being read as a sentence is more Swifty.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Rationale:</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>The following code makes me smile:</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>ApiClient().fetchUsers().then(displayUsers)</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>It exemplifies the beauty of Swift. First-class functions make this line of code read very well. Consider some alternatives:</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>1. ApiClient().fetchUsers().then { displayUsers($0) }</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>2. ApiClient().fetchUsers().then { users in displayUsers(users) }</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>3. ApiClient().fetchUsers().then { (users: [User]) in displayUsers(users) }</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Using the lessons learned from Swift API Design Guidelines (WWDC 2016 Session 403) having an emphasis on clarity, my analysis of the alternatives is:</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>1. $0 adds no additional information as to the type or explanation of what the argument is, thus adding nothing to the line of code for clarity, and therefore should be omitted</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>2. adding "users" also adds nothing to the clarity of the code. The function, properly, contains the information necessary to reason about the argument it takes and what it does, and therefore adding "users" is redundant</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>3. Not only is "users" redundant, but also is the explicit type label. The `displayUsers` method will only accept one type of argument, so we're duplicating information that the compiler (and autocomplete) already gives us</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>With this I conclude that `ApiClient().fetchUsers().then(displayUsers)` is the Swiftiest option.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I want to extend this same logic to when I find myself writing code like this:</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>ApiClient().fetchUsers().then { users in</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>self.users = users</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>}</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>or alternatively, because "users" is likely redundant information again,</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>ApiClient().fetchUsers().then { self.users = $0 }</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Personally I steer clear of `$0` as much as possible, because I very rarely feel that it provides the information necessary for code clarity. But beyond that, this code no longer reads as nicely as the code we had before. </span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Whereas `ApiClient().fetchUsers().then(displayUsers)` flows nicely as a sentence and reads grammatically, `ApiClient().fetchUsers().then { self.users = $0 }` no longer does.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I think this feature could have a simple implementation where the compiler replaces `#set(X)` with `{ X = $0 }`, and I believe it would go a long way with respect to code clarity, especially when X is something longer like `self.view.bounds.origin.x`</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Looking forward to hearing thoughts from the community,</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Austin Feight</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>_______________________________________________</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>swift-evolution mailing list</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>_______________________________________________</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>swift-evolution mailing list</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>_______________________________________________</span><br></blockquote><blockquote type="cite"><span>swift-evolution mailing list</span><br></blockquote><blockquote type="cite"><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br></blockquote><blockquote type="cite"><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></blockquote><span></span><br><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>