Setter methods for vars

*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*

I don’t understand how

    ApiClient().fetchUsers().then(set(users))

leads to

    ApiClient().fetchUsers().then(displayUsers)

Could you clarify with a more extensive example?
What does the function then() do?

-Kenny

···

On Jun 28, 2016, at 11:18 AM, Austin Feight via swift-evolution <swift-evolution@swift.org> wrote:

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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@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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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@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@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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

As an additive feature it's unlikely to be considered in the Swift 3
timeline anyway. You can search the list archive for previous discussion on
lenses. I think David is saying that this proposal looks like it's asking
for a special case where a more general solution might be appropriate.

···

On Tue, Jun 28, 2016 at 6:11 PM Michael Peternell via swift-evolution < swift-evolution@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@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@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@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@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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@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@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@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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Regards
(From mobile)

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?

Not a joke at all. Read first sentence for brief definition.

···

On Jun 29, 2016, at 1:11 AM, Michael Peternell via swift-evolution <swift-evolution@swift.org> wrote:

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@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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I did mean reflection, sorry for the typo :) what I wanted to say in more detail is that if we go with this syntax now (and I'm fairly sure we won't because it's an additive feature), we may regret it post Swift 3 because if a more general implementation requires a different syntax, we are stuck.

Lenses tie well with reflection if for example an advanced equivalent of Mirror returns to you a list of the lenses for the properties of the object. It would allow us, for example, to write serialization libraries much more easily. Add property behaviours to the mix, and now we're going somewhere ;)

···

On 29 Jun 2016, at 01:11, michael.peternell@gmx.at 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@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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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/&gt; | www.austindfeight.com

···

On Tue, Jun 28, 2016 at 7:33 PM, Michael Peternell via swift-evolution < swift-evolution@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@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@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@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@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@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@swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution