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
