<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Speaking as a co-author of a Lens library, the need is far greater for richer data types, typing schemes, and Metaprogramming in general than for first-class lens support. Currently, you can only get to about the level of `Optional` (lens' Optional, not Swift) before the language falls out from under you and you lose generality of implementation. If anything, this proposal could be the start of a great standalone mogenerator-esque tool.<br><br>~Robert Widmann</div><div><br>2016/01/14 20:11、Michael Henson via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> のメッセージ:<br><br></div><blockquote type="cite"><div><div dir="ltr">It's a way of referring to a specific member of a type with a data structure that, when given an instance of the type, behaves as if it's actually a direct reference to that member on that instance.<br><br>If you have:<br><br>struct Example {<div> let name: String</div><div>}<br><br>If you have a Lens for the 'name' member of the 'Example' type:<br><br>let nameLens = Example#name // assume this generates a Lens, for this example<br><br>then you can hold on to that, pass it around, etc. and apply it to any Example instance you might encounter later on.<br><br>The idea comes primarily from Functional Programming. I'm not familiar enough with FP concepts to go into depth about the ways it's useful in that field, but it has come up in Swift because there isn't currently a way to refer to getters and setters on data properties in the same way that you might be able to directly refer to a member function. The Lens approach seems to be the current front-runner for Swift's answer to that problem.<br><br>Mike</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 14, 2016 at 4:44 PM, Andrey Tarantsov <span dir="ltr"><<a href="mailto:andrey@tarantsov.com" target="_blank">andrey@tarantsov.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Could you please explain what a lens is/means? I only found [1], but quick skimming didn't reveal any lenses.<div><br></div><div>[1] <a href="https://www.youtube.com/watch?v=estNbh2TF3E" target="_blank">https://www.youtube.com/watch?v=estNbh2TF3E</a><br><div><br></div><div>A.</div><div><br></div><div><br><div><blockquote type="cite"><div><div class="h5"><div>On Jan 15, 2016, at 6:10 AM, Michael Henson via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br></div></div><div><div><div class="h5"><div dir="ltr">There hasn't been a major Lens thread on the list so far, but I'm intrigued by the idea and was tinkering with a related proposal until I stumbled across Brandon William's "Lenses in Swift" video and discovered that Lenses cover everything I wanted to do and more.<br><br>The one thing that stuck with me, though, is the question of syntax. If Lenses are to be a native part of the Swift language, how would one declare them?<br><br>We've currently got not-so-secret methods at the type level of Structs and Classes for every member function:<br><br>class Example {<div> func action() {}</div><div>}</div><div><br></div><div>let example = Example()</div><div>example.action // () -> Void</div><div>Example.action // (Example) -> Void<br><br>That looks a lot like a Lens on the member function, though if I understand correctly the current plan is for those to go away in a future version.<br><br>We also have to deal with Type-level members and functions:<br><br>class Example {</div><div> static action() {}</div><div> static name: String</div><div>}</div><div><br></div><div>Example.action() // () -> Void<br>Example.name // String<br><br>So, using a dot-operator as the way to get a Lens could be problematic due to name collisions.<br><br>The Proposal:<br><br>Use the '#' character in place of the dot operator to retrieve a Lens for a Type/member pair:<br><br>Example#action() // (Example) -> Void<br>Example#name // Lens<Example,String>, autogenerated to work on the 'name' member</div><div><br>Member function names should be fully-specified with the mechanism from Doug Gregor's method naming proposal.<br><br>Some notes:<br>* A specific operator stands out and is easier to scan for as a code reader.</div><div>* The octothorpe seems to be available in Swift.<br></div><div>* It also has a current meaning in a technology familiar to most everyone - the Document Fragment in HTML - which could make the idea easier to explain to newcomers, by analogy.<br><br>What about Lenses on Type-level members? My first thought is that we don't have to support that because they're more like namespaced globals rather than parts of a data type. They can always be referenced directly. That might be a vacuous observation to people more familiar with the Lens concept, but I noted it for completeness.<br><br>Mike</div></div>
</div></div><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=LRtxqIpN0uduUbaiFaLozLZv7i-2BSLNOBgkrlBNK2PSWsFR-2F8KF21afhZNNq3EK6M8imH-2B-2FGE8E7MBylPP43W5v-2FvrjRDh-2F4oEV6NGtgBM9nIbQYZ5jLkI9uhy3q4tLRtEa-2BHi-2B-2Fksq-2FVSjS9ior3ppVLzjHpxrwSs9b4o6Xd-2Fm3cfqAiW6cjRzt3xh8EXx-2FqVe7H8UIxwb7tKZFsWX5mOyPF1cGrNH9ZQxpMkGQ-2FHpI-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
_______________________________________________<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" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></div></div></blockquote></div><br></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=NX5pLVYXK-2FsoGvk-2BsN3ORSjM6f2-2BhaPL1hRr1LvA7673LNhbeykn5MdkU5dynzZ5bolLUGoVLg5ysIDJassL7Q4a0PfiPgYIOR60pXAJmticVZmclNu6L-2F6Po89sNJuEs-2BPZxsTWMp4be44fht22AwozmDZtKxkzdaSwsEKGwOfhxXtyGzPbyE4Uz4Ip0wcQKPneb2gRc7Q4OsXRZKaMqeu74fg-2BMDhelmWRaS5ekUU-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;">
</div></blockquote><blockquote type="cite"><div><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>