Built-in lenses would solve this issue and much more, didn't know it was on the list already!
*Austin Feight *| Chief Shipping Officer 150 E. 52nd Street, 22nd Floor, New York, NY 10022 www.chexology.com <http://www.coatchex.com/> | www.austindfeight.com On Tue, Jun 28, 2016 at 7:33 PM, Michael Peternell via swift-evolution < [email protected]> wrote: > Haha, I think if we support lenses we should also support a QBit > structure, because lenses are just special cases for QBits ;) That said, I > think it's unlikely that lenses will be supported in Swift 4. We should > wait for Swift 5 when the full QBit-library will be introduced > (hardware-accellerated of course, but it deploys back until the iPhone 6S.) > > Good night guys (it's 1:30 am in my time zone...) > > -Michael > > > Am 29.06.2016 um 01:22 schrieb Sean Heber via swift-evolution < > [email protected]>: > > > > 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: https://www21.in.tum.de/teaching/fp/SS15/papers/17.pdf > > > > l8r > > Sean > > > > Sent from my iPad > > > > On Jun 28, 2016, at 6:11 PM, Michael Peternell via swift-evolution < > [email protected]> wrote: > > > >> Really?? Or we just have #set and #get and no lenses, and it's done for > Swift 3? > >> > >> 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? > >> > >> -Michael > >> > >>> Am 29.06.2016 um 00:55 schrieb David Hart via swift-evolution < > [email protected]>: > >>> > >>> 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. > >>> > >>>> On 28 Jun 2016, at 22:04, Michael Peternell via swift-evolution < > [email protected]> wrote: > >>>> > >>>> 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`.. > >>>> > >>>> 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.) > >>>> > >>>> `#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. > >>>> > >>>> -Michael > >>>> > >>>>> Am 28.06.2016 um 20:18 schrieb Austin Feight via swift-evolution < > [email protected]>: > >>>>> > >>>>> Proposal: > >>>>> > >>>>> I propose adding setter methods to vars, which could look something > like this: `ApiClient().fetchUsers().then(#set(users))` > >>>>> > >>>>> Initially I thought it should work like this: > `ApiClient().fetchUsers().then(users.set)` > >>>>> 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. > >>>>> > >>>>> Rationale: > >>>>> > >>>>> The following code makes me smile: > >>>>> > >>>>> ApiClient().fetchUsers().then(displayUsers) > >>>>> > >>>>> It exemplifies the beauty of Swift. First-class functions make this > line of code read very well. Consider some alternatives: > >>>>> > >>>>> 1. ApiClient().fetchUsers().then { displayUsers($0) } > >>>>> 2. ApiClient().fetchUsers().then { users in displayUsers(users) } > >>>>> 3. ApiClient().fetchUsers().then { (users: [User]) in > displayUsers(users) } > >>>>> > >>>>> Using the lessons learned from Swift API Design Guidelines (WWDC > 2016 Session 403) having an emphasis on clarity, my analysis of the > alternatives is: > >>>>> > >>>>> 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 > >>>>> 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 > >>>>> 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 > >>>>> > >>>>> With this I conclude that > `ApiClient().fetchUsers().then(displayUsers)` is the Swiftiest option. > >>>>> I want to extend this same logic to when I find myself writing code > like this: > >>>>> > >>>>> ApiClient().fetchUsers().then { users in > >>>>> self.users = users > >>>>> } > >>>>> > >>>>> or alternatively, because "users" is likely redundant information > again, > >>>>> > >>>>> ApiClient().fetchUsers().then { self.users = $0 } > >>>>> > >>>>> 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. > >>>>> > >>>>> Whereas `ApiClient().fetchUsers().then(displayUsers)` flows nicely > as a sentence and reads grammatically, `ApiClient().fetchUsers().then { > self.users = $0 }` no longer does. > >>>>> > >>>>> 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` > >>>>> > >>>>> > >>>>> Looking forward to hearing thoughts from the community, > >>>>> Austin Feight > >>>>> _______________________________________________ > >>>>> swift-evolution mailing list > >>>>> [email protected] > >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution > >>>> > >>>> _______________________________________________ > >>>> swift-evolution mailing list > >>>> [email protected] > >>>> https://lists.swift.org/mailman/listinfo/swift-evolution > >>> > >>> _______________________________________________ > >>> swift-evolution mailing list > >>> [email protected] > >>> https://lists.swift.org/mailman/listinfo/swift-evolution > >> > >> _______________________________________________ > >> swift-evolution mailing list > >> [email protected] > >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > > swift-evolution mailing list > > [email protected] > > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
