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
