As an additive feature it&#39;s unlikely to be considered in the Swift 3 timeline anyway. You can search the list archive for previous discussion on lenses. I think David is saying that this proposal looks like it&#39;s asking for a special case where a more general solution might be appropriate.<br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 28, 2016 at 6:11 PM Michael Peternell via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Really?? Or we just have #set and #get and no lenses, and it&#39;s done for Swift 3?<br>
<br>
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&#39;m not sure what you were trying to say. Reflexion -&gt; Reflection?<br>
<br>
-Michael<br>
<br>
&gt; Am 29.06.2016 um 00:55 schrieb David Hart via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;:<br>
&gt;<br>
&gt; 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.<br>
&gt;<br>
&gt;&gt; On 28 Jun 2016, at 22:04, Michael Peternell via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; So you&#39;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`..<br>
&gt;&gt;<br>
&gt;&gt; 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.)<br>
&gt;&gt;<br>
&gt;&gt; `#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.<br>
&gt;&gt;<br>
&gt;&gt; -Michael<br>
&gt;&gt;<br>
&gt;&gt;&gt; Am 28.06.2016 um 20:18 schrieb Austin Feight via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Proposal:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I propose adding setter methods to vars, which could look something like this: `ApiClient().fetchUsers().then(#set(users))`<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Initially I thought it should work like this: `ApiClient().fetchUsers().then(users.set)`<br>
&gt;&gt;&gt; but to accomplish a line of code that flows grammatically, I believe putting &quot;set&quot; where it would naturally fall if the code was being read as a sentence is more Swifty.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Rationale:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; The following code makes me smile:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; ApiClient().fetchUsers().then(displayUsers)<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; It exemplifies the beauty of Swift. First-class functions make this line of code read very well. Consider some alternatives:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 1. ApiClient().fetchUsers().then { displayUsers($0) }<br>
&gt;&gt;&gt; 2. ApiClient().fetchUsers().then { users in displayUsers(users) }<br>
&gt;&gt;&gt; 3. ApiClient().fetchUsers().then { (users: [User]) in displayUsers(users) }<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Using the lessons learned from Swift API Design Guidelines (WWDC 2016 Session 403) having an emphasis on clarity, my analysis of the alternatives is:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 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<br>
&gt;&gt;&gt; 2. adding &quot;users&quot; 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 &quot;users&quot; is redundant<br>
&gt;&gt;&gt; 3. Not only is &quot;users&quot; redundant, but also is the explicit type label. The `displayUsers` method will only accept one type of argument, so we&#39;re duplicating information that the compiler (and autocomplete) already gives us<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; With this I conclude that `ApiClient().fetchUsers().then(displayUsers)` is the Swiftiest option.<br>
&gt;&gt;&gt; I want to extend this same logic to when I find myself writing code like this:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; ApiClient().fetchUsers().then { users in<br>
&gt;&gt;&gt; self.users = users<br>
&gt;&gt;&gt; }<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; or alternatively, because &quot;users&quot; is likely redundant information again,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; ApiClient().fetchUsers().then { self.users = $0 }<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 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.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Whereas `ApiClient().fetchUsers().then(displayUsers)` flows nicely as a sentence and reads grammatically, `ApiClient().fetchUsers().then { self.users = $0 }` no longer does.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 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`<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Looking forward to hearing thoughts from the community,<br>
&gt;&gt;&gt; Austin Feight<br>
&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt; swift-evolution mailing list<br>
&gt;&gt;&gt; <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt;&gt;&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; swift-evolution mailing list<br>
&gt;&gt; <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt;&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; swift-evolution mailing list<br>
&gt; <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>