[swift-evolution] Setter methods for vars

Tue Jun 28 18:40:06 CDT 2016

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 <
swift-evolution at swift.org> 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 <
> swift-evolution at swift.org>:
> >
> > 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 <
> swift-evolution at swift.org> 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 <
> swift-evolution at swift.org>:
> >>>
> >>> 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 <
> swift-evolution at swift.org> 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 <
> swift-evolution at swift.org>:
> >>>>>
> >>>>> 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
> >>>>> swift-evolution at swift.org
> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> >>>>
> >>>> _______________________________________________
> >>>> swift-evolution mailing list
> >>>> swift-evolution at swift.org
> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> >>>
> >>> _______________________________________________
> >>> swift-evolution mailing list
> >>> swift-evolution at swift.org
> >>> https://lists.swift.org/mailman/listinfo/swift-evolution
> >>
> >> _______________________________________________
> >> swift-evolution mailing list
> >> swift-evolution at swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160628/743eec75/attachment.html>