Re: [swift-evolution] Reduce with inout

[Daniel Duan via swift-evolution]

Ping.

What’s the latest on this proposal? Seems like a clear win to me. It seems the 
thread converged on a name if we want 2 versions of reduce. Should we simply 
replace the existing version so there’s only one?

Really wish this can get in Swift 4.
> On Jan 25, 2017, at 1:06 AM, Chris Eidhof via swift-evolution 
>  wrote:
> 
> I like it too! Thanks Pyry! Will change the proposal.
> 
> On Wed, Jan 25, 2017 at 8:09 AM, David Hart via swift-evolution 
> > wrote:
> Yep, that's really good.
> 
> On 25 Jan 2017, at 08:00, Jonathan Hull via swift-evolution 
> > wrote:
> 
>> +1  Best so far.
>> 
>>> On Jan 24, 2017, at 10:36 AM, Pyry Jahkola via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>> Freak Show wrote:
>>> 
 Am I the only one who finds this incredibly ugly and hard to read?
 
 This is more or less solved by inject:into: idiom.  There is no reason for 
 inout for this particular problem.
>>> 
>>> Yeah, the original signature seems more useful. If you go all `inout` like 
>>> Gwendal suggested, you might as well just iterate over the sequence with 
>>> `for x in xs`, updating the state as you go.
>>> 
>>> But your comment brought another idea to mind: if `mutating:` is considered 
>>> a bad name for a non-`inout` argument, how about `reduce(into:combine:)`, 
>>> similar to what Karl suggested earlier in this thread?
>>> 
>>> I think it reads very well at the call site, does not suggest `inout`ness 
>>> of the argument too much (of course there's no `&` at the call site 
>>> either), and it's still easily found with auto-completion:
>>> 
>>> let counts = words.reduce(into: [:]) {
>>>   $0[$1] = ($0[$1] ?? 0) + 1
>>> }
>>> 
>>> — Pyry
>>> ___
>>> 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 
> 
> 
> 
> 
> 
> -- 
> Chris Eidhof
> ___
> 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

Re: [swift-evolution] Reduce with inout

[Ehrlich Family via swift-evolution]

Should combine be allowed to throw, thus forcing this method to rethrow?

 Begin Message  
Group: gmane.comp.lang.swift.evolution 
MsgID: 

[swift-evolution] Reduce with inout

[Ehrlich Family via swift-evolution]

Apologies if this reply comes across the list multiple times...

Should combine be allowed to throw, thus forcing this method to rethrow?

>  Begin Message  
> Group: gmane.comp.lang.swift.evolution 
> MsgID: 

Re: [swift-evolution] Reduce with inout

[Chris Eidhof via swift-evolution]

I like it too! Thanks Pyry! Will change the proposal.

On Wed, Jan 25, 2017 at 8:09 AM, David Hart via swift-evolution <
swift-evolution@swift.org> wrote:

> Yep, that's really good.
>
> On 25 Jan 2017, at 08:00, Jonathan Hull via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> +1  Best so far.
>
> On Jan 24, 2017, at 10:36 AM, Pyry Jahkola via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> Freak Show wrote:
>
> Am I the only one who finds this incredibly ugly and hard to read?
>
> This is more or less solved by inject:into: idiom.  There is no reason for
> inout for this particular problem.
>
>
> Yeah, the original signature seems more useful. If you go all `inout` like
> Gwendal suggested, you might as well just iterate over the sequence with
> `for x in xs`, updating the state as you go.
>
> But your comment brought another idea to mind: if `mutating:` is
> considered a bad name for a non-`inout` argument, how about `
> *reduce(into:combine:)`*, similar to what Karl suggested earlier in this
> thread?
>
> I think it reads very well at the call site, does not suggest `inout`ness
> of the argument too much (of course there's no `&` at the call site
> either), and it's still easily found with auto-completion:
>
> let counts = words.reduce(into: [:]) {
>   $0[$1] = ($0[$1] ?? 0) + 1
> }
>
> — Pyry
> ___
> 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
>
>


-- 
Chris Eidhof
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Reduce with inout

[Jonathan Hull via swift-evolution]

+1  Best so far.

> On Jan 24, 2017, at 10:36 AM, Pyry Jahkola via swift-evolution 
>  wrote:
> 
> 
> Freak Show wrote:
> 
>> Am I the only one who finds this incredibly ugly and hard to read?
>> 
>> This is more or less solved by inject:into: idiom.  There is no reason for 
>> inout for this particular problem.
> 
> Yeah, the original signature seems more useful. If you go all `inout` like 
> Gwendal suggested, you might as well just iterate over the sequence with `for 
> x in xs`, updating the state as you go.
> 
> But your comment brought another idea to mind: if `mutating:` is considered a 
> bad name for a non-`inout` argument, how about `reduce(into:combine:)`, 
> similar to what Karl suggested earlier in this thread?
> 
> I think it reads very well at the call site, does not suggest `inout`ness of 
> the argument too much (of course there's no `&` at the call site either), and 
> it's still easily found with auto-completion:
> 
> let counts = words.reduce(into: [:]) {
>   $0[$1] = ($0[$1] ?? 0) + 1
> }
> 
> — Pyry
> ___
> 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

Re: [swift-evolution] Reduce with inout

[Xiaodi Wu via swift-evolution]

Hmm, good point--none come to mind.


On Tue, Jan 24, 2017 at 14:03 Matthew Johnson 
wrote:

On Jan 24, 2017, at 1:27 PM, Xiaodi Wu  wrote:

Hmm, brainstorming here. Given the pervasive use of `with` to mean "this
isn't accessible otherwise but inside this closure it's $0", maybe
`reduce(with: 42) { $0 += 1 }` might give a useful hint?


Are there any current uses of `with` passed `inout`?

On Tue, Jan 24, 2017 at 13:19 Matthew Johnson 
wrote:

On Jan 24, 2017, at 1:01 PM, Xiaodi Wu  wrote:

Hmm, it reads well, but IMO it avoids being misleading only because it
doesn't mean anything. In what way are you reducing "into" the first
argument any more so than the classic reduce function?


It isn't perfect, but it’s better than the alternatives I’ve seen so far.

In the classic reduce function a new value is produced for each step of the
reduction.  In this variation, each step reduces “into” an accumulator that
is initialized with the seed value.  In that sense, you could say that you
reduce “into” the seed value.

Labeling the argument `into` is a little bit of a stretch but I think it's
far superior to `mutating` which is pretty misleading at the call site.  I
think it would be pretty hard to come up with something better, but let’s
keep the bikeshed going if anyone has additional ideas.


On Tue, Jan 24, 2017 at 12:44 Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

On Jan 24, 2017, at 12:36 PM, Pyry Jahkola via swift-evolution <
swift-evolution@swift.org> wrote:


Freak Show wrote:

Am I the only one who finds this incredibly ugly and hard to read?

This is more or less solved by inject:into: idiom.  There is no reason for
inout for this particular problem.


Yeah, the original signature seems more useful. If you go all `inout` like
Gwendal suggested, you might as well just iterate over the sequence with
`for x in xs`, updating the state as you go.

But your comment brought another idea to mind: if `mutating:` is considered
a bad name for a non-`inout` argument, how about `*reduce(into:combine:)`*,
similar to what Karl suggested earlier in this thread?

I think it reads very well at the call site, does not suggest `inout`ness
of the argument too much (of course there's no `&` at the call site
either), and it's still easily found with auto-completion:

let counts = words.reduce(into: [:]) {
  $0[$1] = ($0[$1] ?? 0) + 1
}


+1.  This is concise and I think it captures the essence of what is
happening pretty well!

The third variation where the seed argument actually *is* `inout` might
also be interesting in some cases where you *already* have a `var` that you
want to accumulate into.  I believe I have done this in the past in my own
code but don’t have an example handy.


— Pyry
___
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

Re: [swift-evolution] Reduce with inout

[Matthew Johnson via swift-evolution]

> On Jan 24, 2017, at 1:27 PM, Xiaodi Wu  wrote:
> 
> Hmm, brainstorming here. Given the pervasive use of `with` to mean "this 
> isn't accessible otherwise but inside this closure it's $0", maybe 
> `reduce(with: 42) { $0 += 1 }` might give a useful hint?

Are there any current uses of `with` passed `inout`?

> On Tue, Jan 24, 2017 at 13:19 Matthew Johnson  > wrote:
>> On Jan 24, 2017, at 1:01 PM, Xiaodi Wu > > wrote:
>> 
>> Hmm, it reads well, but IMO it avoids being misleading only because it 
>> doesn't mean anything. In what way are you reducing "into" the first 
>> argument any more so than the classic reduce function?
> 
> It isn't perfect, but it’s better than the alternatives I’ve seen so far.
> 
> In the classic reduce function a new value is produced for each step of the 
> reduction.  In this variation, each step reduces “into” an accumulator that 
> is initialized with the seed value.  In that sense, you could say that you 
> reduce “into” the seed value.
> 
> Labeling the argument `into` is a little bit of a stretch but I think it's 
> far superior to `mutating` which is pretty misleading at the call site.  I 
> think it would be pretty hard to come up with something better, but let’s 
> keep the bikeshed going if anyone has additional ideas.
> 
> 
>> On Tue, Jan 24, 2017 at 12:44 Matthew Johnson via swift-evolution 
>> > wrote:
>>> On Jan 24, 2017, at 12:36 PM, Pyry Jahkola via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>> Freak Show wrote:
>>> 
 Am I the only one who finds this incredibly ugly and hard to read?
 
 This is more or less solved by inject:into: idiom.  There is no reason for 
 inout for this particular problem.
>>> 
>>> Yeah, the original signature seems more useful. If you go all `inout` like 
>>> Gwendal suggested, you might as well just iterate over the sequence with 
>>> `for x in xs`, updating the state as you go.
>>> 
>>> But your comment brought another idea to mind: if `mutating:` is considered 
>>> a bad name for a non-`inout` argument, how about `reduce(into:combine:)`, 
>>> similar to what Karl suggested earlier in this thread?
>>> 
>>> I think it reads very well at the call site, does not suggest `inout`ness 
>>> of the argument too much (of course there's no `&` at the call site 
>>> either), and it's still easily found with auto-completion:
>>> 
>>> let counts = words.reduce(into: [:]) {
>>>   $0[$1] = ($0[$1] ?? 0) + 1
>>> }
>> 
>> +1.  This is concise and I think it captures the essence of what is 
>> happening pretty well!
>> 
>> The third variation where the seed argument actually *is* `inout` might also 
>> be interesting in some cases where you *already* have a `var` that you want 
>> to accumulate into.  I believe I have done this in the past in my own code 
>> but don’t have an example handy.
>> 
>>> 
>>> — Pyry
>>> ___
>>> 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

Re: [swift-evolution] Reduce with inout

[Xiaodi Wu via swift-evolution]

Hmm, brainstorming here. Given the pervasive use of `with` to mean "this
isn't accessible otherwise but inside this closure it's $0", maybe
`reduce(with: 42) { $0 += 1 }` might give a useful hint?
On Tue, Jan 24, 2017 at 13:19 Matthew Johnson 
wrote:

> On Jan 24, 2017, at 1:01 PM, Xiaodi Wu  wrote:
>
> Hmm, it reads well, but IMO it avoids being misleading only because it
> doesn't mean anything. In what way are you reducing "into" the first
> argument any more so than the classic reduce function?
>
>
> It isn't perfect, but it’s better than the alternatives I’ve seen so far.
>
> In the classic reduce function a new value is produced for each step of
> the reduction.  In this variation, each step reduces “into” an accumulator
> that is initialized with the seed value.  In that sense, you could say that
> you reduce “into” the seed value.
>
> Labeling the argument `into` is a little bit of a stretch but I think it's
> far superior to `mutating` which is pretty misleading at the call site.  I
> think it would be pretty hard to come up with something better, but let’s
> keep the bikeshed going if anyone has additional ideas.
>
>
> On Tue, Jan 24, 2017 at 12:44 Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Jan 24, 2017, at 12:36 PM, Pyry Jahkola via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> Freak Show wrote:
>
> Am I the only one who finds this incredibly ugly and hard to read?
>
> This is more or less solved by inject:into: idiom.  There is no reason for
> inout for this particular problem.
>
>
> Yeah, the original signature seems more useful. If you go all `inout` like
> Gwendal suggested, you might as well just iterate over the sequence with
> `for x in xs`, updating the state as you go.
>
> But your comment brought another idea to mind: if `mutating:` is
> considered a bad name for a non-`inout` argument, how about `
> *reduce(into:combine:)`*, similar to what Karl suggested earlier in this
> thread?
>
> I think it reads very well at the call site, does not suggest `inout`ness
> of the argument too much (of course there's no `&` at the call site
> either), and it's still easily found with auto-completion:
>
> let counts = words.reduce(into: [:]) {
>   $0[$1] = ($0[$1] ?? 0) + 1
> }
>
>
> +1.  This is concise and I think it captures the essence of what is
> happening pretty well!
>
> The third variation where the seed argument actually *is* `inout` might
> also be interesting in some cases where you *already* have a `var` that you
> want to accumulate into.  I believe I have done this in the past in my own
> code but don’t have an example handy.
>
>
> — Pyry
> ___
> 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

Re: [swift-evolution] Reduce with inout

[Matthew Johnson via swift-evolution]

> On Jan 24, 2017, at 1:01 PM, Xiaodi Wu  wrote:
> 
> Hmm, it reads well, but IMO it avoids being misleading only because it 
> doesn't mean anything. In what way are you reducing "into" the first argument 
> any more so than the classic reduce function?

It isn't perfect, but it’s better than the alternatives I’ve seen so far.

In the classic reduce function a new value is produced for each step of the 
reduction.  In this variation, each step reduces “into” an accumulator that is 
initialized with the seed value.  In that sense, you could say that you reduce 
“into” the seed value.

Labeling the argument `into` is a little bit of a stretch but I think it's far 
superior to `mutating` which is pretty misleading at the call site.  I think it 
would be pretty hard to come up with something better, but let’s keep the 
bikeshed going if anyone has additional ideas.


> On Tue, Jan 24, 2017 at 12:44 Matthew Johnson via swift-evolution 
> > wrote:
>> On Jan 24, 2017, at 12:36 PM, Pyry Jahkola via swift-evolution 
>> > wrote:
>> 
>> 
>> Freak Show wrote:
>> 
>>> Am I the only one who finds this incredibly ugly and hard to read?
>>> 
>>> This is more or less solved by inject:into: idiom.  There is no reason for 
>>> inout for this particular problem.
>> 
>> Yeah, the original signature seems more useful. If you go all `inout` like 
>> Gwendal suggested, you might as well just iterate over the sequence with 
>> `for x in xs`, updating the state as you go.
>> 
>> But your comment brought another idea to mind: if `mutating:` is considered 
>> a bad name for a non-`inout` argument, how about `reduce(into:combine:)`, 
>> similar to what Karl suggested earlier in this thread?
>> 
>> I think it reads very well at the call site, does not suggest `inout`ness of 
>> the argument too much (of course there's no `&` at the call site either), 
>> and it's still easily found with auto-completion:
>> 
>> let counts = words.reduce(into: [:]) {
>>   $0[$1] = ($0[$1] ?? 0) + 1
>> }
> 
> +1.  This is concise and I think it captures the essence of what is happening 
> pretty well!
> 
> The third variation where the seed argument actually *is* `inout` might also 
> be interesting in some cases where you *already* have a `var` that you want 
> to accumulate into.  I believe I have done this in the past in my own code 
> but don’t have an example handy.
> 
>> 
>> — Pyry
>> ___
>> 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

Re: [swift-evolution] Reduce with inout

[Matthew Johnson via swift-evolution]

> On Jan 24, 2017, at 12:36 PM, Pyry Jahkola via swift-evolution 
>  wrote:
> 
> 
> Freak Show wrote:
> 
>> Am I the only one who finds this incredibly ugly and hard to read?
>> 
>> This is more or less solved by inject:into: idiom.  There is no reason for 
>> inout for this particular problem.
> 
> Yeah, the original signature seems more useful. If you go all `inout` like 
> Gwendal suggested, you might as well just iterate over the sequence with `for 
> x in xs`, updating the state as you go.
> 
> But your comment brought another idea to mind: if `mutating:` is considered a 
> bad name for a non-`inout` argument, how about `reduce(into:combine:)`, 
> similar to what Karl suggested earlier in this thread?
> 
> I think it reads very well at the call site, does not suggest `inout`ness of 
> the argument too much (of course there's no `&` at the call site either), and 
> it's still easily found with auto-completion:
> 
> let counts = words.reduce(into: [:]) {
>   $0[$1] = ($0[$1] ?? 0) + 1
> }

+1.  This is concise and I think it captures the essence of what is happening 
pretty well!

The third variation where the seed argument actually *is* `inout` might also be 
interesting in some cases where you *already* have a `var` that you want to 
accumulate into.  I believe I have done this in the past in my own code but 
don’t have an example handy.

> 
> — Pyry
> ___
> 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

Re: [swift-evolution] Reduce with inout

[Pyry Jahkola via swift-evolution]

> Freak Show wrote:
> 
> Am I the only one who finds this incredibly ugly and hard to read?
> 
> This is more or less solved by inject:into: idiom.  There is no reason for 
> inout for this particular problem.

Yeah, the original signature seems more useful. If you go all `inout` like 
Gwendal suggested, you might as well just iterate over the sequence with `for x 
in xs`, updating the state as you go.

But your comment brought another idea to mind: if `mutating:` is considered a 
bad name for a non-`inout` argument, how about `reduce(into:combine:)`, similar 
to what Karl suggested earlier in this thread?

I think it reads very well at the call site, does not suggest `inout`ness of 
the argument too much (of course there's no `&` at the call site either), and 
it's still easily found with auto-completion:

let counts = words.reduce(into: [:]) {
  $0[$1] = ($0[$1] ?? 0) + 1
}

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

Re: [swift-evolution] Reduce with inout

[Freak Show via swift-evolution]

Am I the only one who finds this incredibly ugly and hard to read?

This is more or less solved by inject:into: idiom.  There is no reason for 
inout for this particular problem.


> On Jan 24, 2017, at 06:43, Gwendal Roué via swift-evolution 
>  wrote:
> 
> But what if we stop fighting? Isn't the following code the correct version of 
> Chris's vision ?
> 
> extension Sequence {
> func reduce(mutating result: inout A, _ combine: (inout A, 
> Iterator.Element) -> ()) {
> for element in self {
> combine(, element)
> }
> }
> }
> 
> extension Sequence where Iterator.Element: Equatable {
> func uniq() -> [Iterator.Element] {
> var result: [Iterator.Element] = [] // meh
> reduce(mutating: ) { (result: inout [Iterator.Element], 
> element) in
> if result.last != element {
> result.append(element)
> }
> }
> return result
> }
> }
> 
> let x = [1, 1, 2, 3]
> x.uniq() // [1, 2, 3]

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

Re: [swift-evolution] Reduce with inout

[Xiaodi Wu via swift-evolution]

Yes, Matthew, I agree with you exactly on this. It's tricky. `copyOf` isn't
ideal at all, but `mutating` is potentially misleading. Ah the difficulties
of naming things.


On Tue, Jan 24, 2017 at 09:15 Matthew Johnson 
wrote:

> On Jan 24, 2017, at 8:12 AM, Chris Eidhof  wrote:
>
> But if we want to add "copyOf" we should do that to every method that
> takes a struct? Also, what if you pass in an object?
>
> I see the concern, but I don't think adding `copyOf` will increase
> clarity. That said, I'm open to suggestions.
>
>
> I’m not really trying to advocate for “copyOf”.  I think we should really
> have something more concise in a case like this.  My main point is that
> just using `mutating` is inaccurate and therefore probably not the right
> solution.
>
> Your question about passing in an object (I assume you mean a reference
> type here) is a good one.  In an ideal world that would probably not be
> allowed as it doesn’t really make sense to replace the reference during
> reduction.  Unfortunately I don’t think we have a way to prevent that at
> the moment.
>
>
> On Tue, Jan 24, 2017 at 2:43 PM, Xiaodi Wu  wrote:
>
> It's only verbose if the words aren't needed! The shortest way to describe
> something with sufficient accuracy can never be verbose, let alone
> undesirable, and I highly agree with this concern. We already have names of
> this form, such as `FloatingPoint.init(signOf:magnitudeOf:)`.
>
>
> I mostly agree with this Xiaodi, but I also think that commonly known and
> frequently used methods like `reduce` deserve to be as concise as
> possible.  That is less a concern with less common and less frequently used
> signatures.
>
>
> On Tue, Jan 24, 2017 at 07:33 Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> Sent from my iPad
>
> On Jan 24, 2017, at 1:54 AM, Chris Eidhof via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I've thought about it for a few days, and really like
> `reduce(mutating:_)`.
>
>
> I'm not a fan of this.  It reads in a way that makes it seem like the
> parameter should be inout, but it isn't.  A variation of reduce where the
> initial value parameter *is* inout is perfectly sensible (whether or not we
> want it in the standard library).  With that in mind, I don't think we
> should use this name.
>
> Unfortunately I don't have a better suggestion.  I think it was Brent who
> suggested "mutatingCopyOf" which is more accurate, but also undesirably
> verbose.
>
> I've updated the PR, and am now happy for this to go into review.
>
> https://github.com/apple/swift-evolution/pull/587
>
> On Mon, Jan 23, 2017 at 8:27 AM, Russ Bishop  wrote:
>
>
> On Jan 22, 2017, at 10:56 PM, Chris Eidhof  wrote:
>
> Not as a direct reply to Russ, but just to reiterate: to me, there are two
> clear benefits of using the `inout` version of reduce:
>
> 1. The performance (currently discussed at length)
> 2. Readability (because we can use mutating methods on `inout` arguments).
>
> Even if the compiler were to optimize the unnecessary copy of `return arr
> + [el]` away, there are still a lot of other mutable methods that you might
> want to use within the reduce closure. So I think the proposal is still
> very valid even if the compiler optimizations would magically appear
> tomorrow.
>
> To push this proposal forward a little bit, I'd like to come up with a
> good name. It seems like we shouldn't overload `reduce`, but choose a
> different name, so that we don't stress the typechecker. Any other
> suggestions?
>
> On Mon, Jan 23, 2017 at 7:11 AM, Russ Bishop  wrote:
> --
> Chris Eidhof
>
>
>
> Sorry for the derail!
>
> reduce(mutating:_:) { } is still my favorite; You can take mutating to
> mean we will copy the value now but mutate it later.
>
>
> Some alternatives:
>
> reduce(forMutating:_:) { }
>
> reduce(forInout:_:) { }
>
> reduce(initial:_:) { }
>
> reduce(copying:mutate:) { }
>
> // just kidding...
> reduce(copyForLaterMutating:_:) { }
>
>
>
> It should definitely be some form of reduce.
>
> Russ
>
>
>
>
> --
> Chris Eidhof
>
> ___
> 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
>
>
>
>
> --
> Chris Eidhof
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Reduce with inout

[Matthew Johnson via swift-evolution]

> On Jan 24, 2017, at 8:12 AM, Chris Eidhof  wrote:
> 
> But if we want to add "copyOf" we should do that to every method that takes a 
> struct? Also, what if you pass in an object?
> 
> I see the concern, but I don't think adding `copyOf` will increase clarity. 
> That said, I'm open to suggestions.

I’m not really trying to advocate for “copyOf”.  I think we should really have 
something more concise in a case like this.  My main point is that just using 
`mutating` is inaccurate and therefore probably not the right solution.

Your question about passing in an object (I assume you mean a reference type 
here) is a good one.  In an ideal world that would probably not be allowed as 
it doesn’t really make sense to replace the reference during reduction.  
Unfortunately I don’t think we have a way to prevent that at the moment.

> 
> On Tue, Jan 24, 2017 at 2:43 PM, Xiaodi Wu  > wrote:
> It's only verbose if the words aren't needed! The shortest way to describe 
> something with sufficient accuracy can never be verbose, let alone 
> undesirable, and I highly agree with this concern. We already have names of 
> this form, such as `FloatingPoint.init(signOf:magnitudeOf:)`.

I mostly agree with this Xiaodi, but I also think that commonly known and 
frequently used methods like `reduce` deserve to be as concise as possible.  
That is less a concern with less common and less frequently used signatures.

> 
> On Tue, Jan 24, 2017 at 07:33 Matthew Johnson via swift-evolution 
> > wrote:
> 
> 
> Sent from my iPad
> 
> On Jan 24, 2017, at 1:54 AM, Chris Eidhof via swift-evolution 
> > wrote:
> 
>> I've thought about it for a few days, and really like `reduce(mutating:_)`.
> 
> I'm not a fan of this.  It reads in a way that makes it seem like the 
> parameter should be inout, but it isn't.  A variation of reduce where the 
> initial value parameter *is* inout is perfectly sensible (whether or not we 
> want it in the standard library).  With that in mind, I don't think we should 
> use this name.  
> 
> Unfortunately I don't have a better suggestion.  I think it was Brent who 
> suggested "mutatingCopyOf" which is more accurate, but also undesirably 
> verbose.
> 
>> I've updated the PR, and am now happy for this to go into review.
>> 
>> https://github.com/apple/swift-evolution/pull/587 
>> 
>> 
>> On Mon, Jan 23, 2017 at 8:27 AM, Russ Bishop > > wrote:
>> 
>>> On Jan 22, 2017, at 10:56 PM, Chris Eidhof >> > wrote:
>>> 
>>> Not as a direct reply to Russ, but just to reiterate: to me, there are two 
>>> clear benefits of using the `inout` version of reduce:
>>> 
>>> 1. The performance (currently discussed at length)
>>> 2. Readability (because we can use mutating methods on `inout` arguments).
>>> 
>>> Even if the compiler were to optimize the unnecessary copy of `return arr + 
>>> [el]` away, there are still a lot of other mutable methods that you might 
>>> want to use within the reduce closure. So I think the proposal is still 
>>> very valid even if the compiler optimizations would magically appear 
>>> tomorrow.
>>> 
>>> To push this proposal forward a little bit, I'd like to come up with a good 
>>> name. It seems like we shouldn't overload `reduce`, but choose a different 
>>> name, so that we don't stress the typechecker. Any other suggestions?
>>> 
>>> On Mon, Jan 23, 2017 at 7:11 AM, Russ Bishop >> > wrote:
>>> -- 
>>> Chris Eidhof
>> 
>> 
>> Sorry for the derail!
>> 
>> reduce(mutating:_:) { } is still my favorite; You can take mutating to mean 
>> we will copy the value now but mutate it later.
>> 
>> 
>> Some alternatives:
>> 
>> reduce(forMutating:_:) { }
>> 
>> reduce(forInout:_:) { }
>> 
>> reduce(initial:_:) { }
>> 
>> reduce(copying:mutate:) { }
>> 
>> // just kidding...
>> reduce(copyForLaterMutating:_:) { }
>> 
>> 
>> 
>> It should definitely be some form of reduce. 
>> 
>> Russ
>> 
>> 
>> 
>> -- 
>> Chris Eidhof
>> ___
>> 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 
> 
> 
> 
> 
> -- 
> Chris Eidhof

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

Re: [swift-evolution] Reduce with inout

[Gwendal Roué via swift-evolution]

I think you're all fighting against the language, and especially against 
`inout`. Because you try to copy and then mutate a value, instead of mutating 
it right away.

I totally understand why: `inout` requires variable declared `var`, and the 
compiler won't auto-generate it for us. We try to avoid polluting our code with 
those extra `var` variables. They make code look messy.

But what if we stop fighting? Isn't the following code the correct version of 
Chris's vision ?

extension Sequence {
func reduce(mutating result: inout A, _ combine: (inout A, 
Iterator.Element) -> ()) {
for element in self {
combine(, element)
}
}
}

extension Sequence where Iterator.Element: Equatable {
func uniq() -> [Iterator.Element] {
var result: [Iterator.Element] = [] // meh
reduce(mutating: ) { (result: inout [Iterator.Element], element) 
in
if result.last != element {
result.append(element)
}
}
return result
}
}

let x = [1, 1, 2, 3]
x.uniq() // [1, 2, 3]

Yes, the extra `var` variable in the implementation of `uniq` is awful. But 
that's a limitation of `inout`. Not a limitation of your imagination when you 
try to find a good name for your method.

I'd suggest us to think about improving Swift so that it starts generating 
those extra `var` variables for us. It would then give:

func f(i: inout Int) { ... }
f(1) // OK, even if mutated result is lost
let x: Int = 2
f(x) // OK, even if mutated result is lost

And reduce(mutating:) would get rid of the extra var:

extension Sequence {
func reduce(mutating result: inout A, _ combine: (inout A, 
Iterator.Element) -> ()) -> A {
for element in self {
combine(, element)
}
return result
}
}

extension Sequence where Iterator.Element: Equatable {
func uniq() -> [Iterator.Element] {
return reduce(mutating: []) { (result: inout [Iterator.Element], 
element) in
if result.last != element {
result.append(element)
}
}
}
}

Gwendal


> Le 24 janv. 2017 à 15:12, Chris Eidhof via swift-evolution 
>  a écrit :
> 
> But if we want to add "copyOf" we should do that to every method that takes a 
> struct? Also, what if you pass in an object?
> 
> I see the concern, but I don't think adding `copyOf` will increase clarity. 
> That said, I'm open to suggestions.
> 
> On Tue, Jan 24, 2017 at 2:43 PM, Xiaodi Wu  > wrote:
> It's only verbose if the words aren't needed! The shortest way to describe 
> something with sufficient accuracy can never be verbose, let alone 
> undesirable, and I highly agree with this concern. We already have names of 
> this form, such as `FloatingPoint.init(signOf:magnitudeOf:)`.
> 
> On Tue, Jan 24, 2017 at 07:33 Matthew Johnson via swift-evolution 
> > wrote:
> 
> 
> Sent from my iPad
> 
> On Jan 24, 2017, at 1:54 AM, Chris Eidhof via swift-evolution 
> > wrote:
> 
>> I've thought about it for a few days, and really like `reduce(mutating:_)`. 
> 
> I'm not a fan of this.  It reads in a way that makes it seem like the 
> parameter should be inout, but it isn't.  A variation of reduce where the 
> initial value parameter *is* inout is perfectly sensible (whether or not we 
> want it in the standard library).  With that in mind, I don't think we should 
> use this name.  
> 
> Unfortunately I don't have a better suggestion.  I think it was Brent who 
> suggested "mutatingCopyOf" which is more accurate, but also undesirably 
> verbose.
> 
>> I've updated the PR, and am now happy for this to go into review.
>> 
>> https://github.com/apple/swift-evolution/pull/587 
>> 
>> 
>> On Mon, Jan 23, 2017 at 8:27 AM, Russ Bishop > > wrote:
>> 
>>> On Jan 22, 2017, at 10:56 PM, Chris Eidhof >> > wrote:
>>> 
>>> Not as a direct reply to Russ, but just to reiterate: to me, there are two 
>>> clear benefits of using the `inout` version of reduce:
>>> 
>>> 1. The performance (currently discussed at length)
>>> 2. Readability (because we can use mutating methods on `inout` arguments).
>>> 
>>> Even if the compiler were to optimize the unnecessary copy of `return arr + 
>>> [el]` away, there are still a lot of other mutable methods that you might 
>>> want to use within the reduce closure. So I think the proposal is still 
>>> very valid even if the compiler optimizations would magically appear 
>>> tomorrow.
>>> 
>>> To push this proposal forward a little bit, I'd like to come up with a good 
>>> name. It seems like we shouldn't overload `reduce`, but choose a different 
>>> name, so that we don't stress the typechecker. Any other 

Re: [swift-evolution] Reduce with inout

[Chris Eidhof via swift-evolution]

But if we want to add "copyOf" we should do that to every method that takes
a struct? Also, what if you pass in an object?

I see the concern, but I don't think adding `copyOf` will increase clarity.
That said, I'm open to suggestions.

On Tue, Jan 24, 2017 at 2:43 PM, Xiaodi Wu  wrote:

> It's only verbose if the words aren't needed! The shortest way to describe
> something with sufficient accuracy can never be verbose, let alone
> undesirable, and I highly agree with this concern. We already have names of
> this form, such as `FloatingPoint.init(signOf:magnitudeOf:)`.
>
> On Tue, Jan 24, 2017 at 07:33 Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>>
>> Sent from my iPad
>>
>> On Jan 24, 2017, at 1:54 AM, Chris Eidhof via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I've thought about it for a few days, and really like
>> `reduce(mutating:_)`.
>>
>>
>> I'm not a fan of this.  It reads in a way that makes it seem like the
>> parameter should be inout, but it isn't.  A variation of reduce where the
>> initial value parameter *is* inout is perfectly sensible (whether or not we
>> want it in the standard library).  With that in mind, I don't think we
>> should use this name.
>>
>> Unfortunately I don't have a better suggestion.  I think it was Brent who
>> suggested "mutatingCopyOf" which is more accurate, but also undesirably
>> verbose.
>>
>> I've updated the PR, and am now happy for this to go into review.
>>
>> https://github.com/apple/swift-evolution/pull/587
>>
>> On Mon, Jan 23, 2017 at 8:27 AM, Russ Bishop  wrote:
>>
>>
>> On Jan 22, 2017, at 10:56 PM, Chris Eidhof  wrote:
>>
>> Not as a direct reply to Russ, but just to reiterate: to me, there are
>> two clear benefits of using the `inout` version of reduce:
>>
>> 1. The performance (currently discussed at length)
>> 2. Readability (because we can use mutating methods on `inout` arguments).
>>
>> Even if the compiler were to optimize the unnecessary copy of `return arr
>> + [el]` away, there are still a lot of other mutable methods that you might
>> want to use within the reduce closure. So I think the proposal is still
>> very valid even if the compiler optimizations would magically appear
>> tomorrow.
>>
>> To push this proposal forward a little bit, I'd like to come up with a
>> good name. It seems like we shouldn't overload `reduce`, but choose a
>> different name, so that we don't stress the typechecker. Any other
>> suggestions?
>>
>> On Mon, Jan 23, 2017 at 7:11 AM, Russ Bishop  wrote:
>> --
>> Chris Eidhof
>>
>>
>>
>> Sorry for the derail!
>>
>> reduce(mutating:_:) { } is still my favorite; You can take mutating to
>> mean we will copy the value now but mutate it later.
>>
>>
>> Some alternatives:
>>
>> reduce(forMutating:_:) { }
>>
>> reduce(forInout:_:) { }
>>
>> reduce(initial:_:) { }
>>
>> reduce(copying:mutate:) { }
>>
>> // just kidding...
>> reduce(copyForLaterMutating:_:) { }
>>
>>
>>
>> It should definitely be some form of reduce.
>>
>> Russ
>>
>>
>>
>>
>> --
>> Chris Eidhof
>>
>> ___
>> 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
>>
>


-- 
Chris Eidhof
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Reduce with inout

[Xiaodi Wu via swift-evolution]

It's only verbose if the words aren't needed! The shortest way to describe
something with sufficient accuracy can never be verbose, let alone
undesirable, and I highly agree with this concern. We already have names of
this form, such as `FloatingPoint.init(signOf:magnitudeOf:)`.
On Tue, Jan 24, 2017 at 07:33 Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> Sent from my iPad
>
> On Jan 24, 2017, at 1:54 AM, Chris Eidhof via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I've thought about it for a few days, and really like
> `reduce(mutating:_)`.
>
>
> I'm not a fan of this.  It reads in a way that makes it seem like the
> parameter should be inout, but it isn't.  A variation of reduce where the
> initial value parameter *is* inout is perfectly sensible (whether or not we
> want it in the standard library).  With that in mind, I don't think we
> should use this name.
>
> Unfortunately I don't have a better suggestion.  I think it was Brent who
> suggested "mutatingCopyOf" which is more accurate, but also undesirably
> verbose.
>
> I've updated the PR, and am now happy for this to go into review.
>
> https://github.com/apple/swift-evolution/pull/587
>
> On Mon, Jan 23, 2017 at 8:27 AM, Russ Bishop  wrote:
>
>
> On Jan 22, 2017, at 10:56 PM, Chris Eidhof  wrote:
>
> Not as a direct reply to Russ, but just to reiterate: to me, there are two
> clear benefits of using the `inout` version of reduce:
>
> 1. The performance (currently discussed at length)
> 2. Readability (because we can use mutating methods on `inout` arguments).
>
> Even if the compiler were to optimize the unnecessary copy of `return arr
> + [el]` away, there are still a lot of other mutable methods that you might
> want to use within the reduce closure. So I think the proposal is still
> very valid even if the compiler optimizations would magically appear
> tomorrow.
>
> To push this proposal forward a little bit, I'd like to come up with a
> good name. It seems like we shouldn't overload `reduce`, but choose a
> different name, so that we don't stress the typechecker. Any other
> suggestions?
>
> On Mon, Jan 23, 2017 at 7:11 AM, Russ Bishop  wrote:
> --
> Chris Eidhof
>
>
>
> Sorry for the derail!
>
> reduce(mutating:_:) { } is still my favorite; You can take mutating to
> mean we will copy the value now but mutate it later.
>
>
> Some alternatives:
>
> reduce(forMutating:_:) { }
>
> reduce(forInout:_:) { }
>
> reduce(initial:_:) { }
>
> reduce(copying:mutate:) { }
>
> // just kidding...
> reduce(copyForLaterMutating:_:) { }
>
>
>
> It should definitely be some form of reduce.
>
> Russ
>
>
>
>
> --
> Chris Eidhof
>
> ___
> 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

Re: [swift-evolution] Reduce with inout

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jan 24, 2017, at 1:54 AM, Chris Eidhof via swift-evolution 
>  wrote:
> 
> I've thought about it for a few days, and really like `reduce(mutating:_)`.

I'm not a fan of this.  It reads in a way that makes it seem like the parameter 
should be inout, but it isn't.  A variation of reduce where the initial value 
parameter *is* inout is perfectly sensible (whether or not we want it in the 
standard library).  With that in mind, I don't think we should use this name.  

Unfortunately I don't have a better suggestion.  I think it was Brent who 
suggested "mutatingCopyOf" which is more accurate, but also undesirably verbose.

> I've updated the PR, and am now happy for this to go into review.
> 
> https://github.com/apple/swift-evolution/pull/587
> 
>> On Mon, Jan 23, 2017 at 8:27 AM, Russ Bishop  wrote:
>> 
>>> On Jan 22, 2017, at 10:56 PM, Chris Eidhof  wrote:
>>> 
>>> Not as a direct reply to Russ, but just to reiterate: to me, there are two 
>>> clear benefits of using the `inout` version of reduce:
>>> 
>>> 1. The performance (currently discussed at length)
>>> 2. Readability (because we can use mutating methods on `inout` arguments).
>>> 
>>> Even if the compiler were to optimize the unnecessary copy of `return arr + 
>>> [el]` away, there are still a lot of other mutable methods that you might 
>>> want to use within the reduce closure. So I think the proposal is still 
>>> very valid even if the compiler optimizations would magically appear 
>>> tomorrow.
>>> 
>>> To push this proposal forward a little bit, I'd like to come up with a good 
>>> name. It seems like we shouldn't overload `reduce`, but choose a different 
>>> name, so that we don't stress the typechecker. Any other suggestions?
>>> 
>>> On Mon, Jan 23, 2017 at 7:11 AM, Russ Bishop  wrote:
>>> -- 
>>> Chris Eidhof
>> 
>> 
>> Sorry for the derail!
>> 
>> reduce(mutating:_:) { } is still my favorite; You can take mutating to mean 
>> we will copy the value now but mutate it later.
>> 
>> 
>> Some alternatives:
>> 
>> reduce(forMutating:_:) { }
>> 
>> reduce(forInout:_:) { }
>> 
>> reduce(initial:_:) { }
>> 
>> reduce(copying:mutate:) { }
>> 
>> // just kidding...
>> reduce(copyForLaterMutating:_:) { }
>> 
>> 
>> 
>> It should definitely be some form of reduce. 
>> 
>> Russ
> 
> 
> 
> -- 
> Chris Eidhof
> ___
> 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

Re: [swift-evolution] Reduce with inout

[Florent Bruneau via swift-evolution]

Hi,

Looks like there is a typo in the proposal:

func reduce(mutating: A, _ combine: (inout A, Iterator.Element) -> ()) 
-> A {
var result = initial

This makes use of `initial` that is not defined, should be:

func reduce(mutating initial: A, _ combine: (inout A, Iterator.Element) 
-> ()) -> A {
var result = initial

> Le 24 janv. 2017 à 08:54, Chris Eidhof via swift-evolution 
>  a écrit :
> 
> I've thought about it for a few days, and really like `reduce(mutating:_)`. 
> I've updated the PR, and am now happy for this to go into review.
> 
> https://github.com/apple/swift-evolution/pull/587
> 
> On Mon, Jan 23, 2017 at 8:27 AM, Russ Bishop  wrote:
> 
>> On Jan 22, 2017, at 10:56 PM, Chris Eidhof  wrote:
>> 
>> Not as a direct reply to Russ, but just to reiterate: to me, there are two 
>> clear benefits of using the `inout` version of reduce:
>> 
>> 1. The performance (currently discussed at length)
>> 2. Readability (because we can use mutating methods on `inout` arguments).
>> 
>> Even if the compiler were to optimize the unnecessary copy of `return arr + 
>> [el]` away, there are still a lot of other mutable methods that you might 
>> want to use within the reduce closure. So I think the proposal is still very 
>> valid even if the compiler optimizations would magically appear tomorrow.
>> 
>> To push this proposal forward a little bit, I'd like to come up with a good 
>> name. It seems like we shouldn't overload `reduce`, but choose a different 
>> name, so that we don't stress the typechecker. Any other suggestions?
>> 
>> On Mon, Jan 23, 2017 at 7:11 AM, Russ Bishop  wrote:
>> -- 
>> Chris Eidhof
> 
> 
> Sorry for the derail!
> 
> reduce(mutating:_:) { } is still my favorite; You can take mutating to mean 
> we will copy the value now but mutate it later.
> 
> 
> Some alternatives:
> 
> reduce(forMutating:_:) { }
> 
> reduce(forInout:_:) { }
> 
> reduce(initial:_:) { }
> 
> reduce(copying:mutate:) { }
> 
> // just kidding...
> reduce(copyForLaterMutating:_:) { }
> 
> 
> 
> It should definitely be some form of reduce. 
> 
> Russ
> 
> 
> 
> -- 
> Chris Eidhof
> ___
> 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

Re: [swift-evolution] Reduce with inout

[Chris Eidhof via swift-evolution]

I've thought about it for a few days, and really like `reduce(mutating:_)`.
I've updated the PR, and am now happy for this to go into review.

https://github.com/apple/swift-evolution/pull/587

On Mon, Jan 23, 2017 at 8:27 AM, Russ Bishop  wrote:

>
> On Jan 22, 2017, at 10:56 PM, Chris Eidhof  wrote:
>
> Not as a direct reply to Russ, but just to reiterate: to me, there are two
> clear benefits of using the `inout` version of reduce:
>
> 1. The performance (currently discussed at length)
> 2. Readability (because we can use mutating methods on `inout` arguments).
>
> Even if the compiler were to optimize the unnecessary copy of `return arr
> + [el]` away, there are still a lot of other mutable methods that you might
> want to use within the reduce closure. So I think the proposal is still
> very valid even if the compiler optimizations would magically appear
> tomorrow.
>
> To push this proposal forward a little bit, I'd like to come up with a
> good name. It seems like we shouldn't overload `reduce`, but choose a
> different name, so that we don't stress the typechecker. Any other
> suggestions?
>
> On Mon, Jan 23, 2017 at 7:11 AM, Russ Bishop  wrote:
> --
> Chris Eidhof
>
>
>
> Sorry for the derail!
>
> reduce(mutating:_:) { } is still my favorite; You can take mutating to
> mean we will copy the value now but mutate it later.
>
>
> Some alternatives:
>
> reduce(forMutating:_:) { }
>
> reduce(forInout:_:) { }
>
> reduce(initial:_:) { }
>
> reduce(copying:mutate:) { }
>
> // just kidding...
> reduce(copyForLaterMutating:_:) { }
>
>
>
> It should definitely be some form of reduce.
>
> Russ
>



-- 
Chris Eidhof
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Reduce with inout

[Chris Eidhof via swift-evolution]

To me, that sounds more like a monomorphic map? (i.e. a `map` that doesn't
change the type).

On Mon, Jan 23, 2017 at 10:07 AM, Jonathan Hull  wrote:

> While we are at it, could we add a inout/mutating version of forEach
> (unless something like that exists and I missed it)?  I have been trying to
> figure out how to run through an array and call a mutating method on each
> element without copying everything, and I am at a loss…
>
> Thanks,
> Jon
>
>
> On Jan 22, 2017, at 11:27 PM, Russ Bishop via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Jan 22, 2017, at 10:56 PM, Chris Eidhof  wrote:
>
> Not as a direct reply to Russ, but just to reiterate: to me, there are two
> clear benefits of using the `inout` version of reduce:
>
> 1. The performance (currently discussed at length)
> 2. Readability (because we can use mutating methods on `inout` arguments).
>
> Even if the compiler were to optimize the unnecessary copy of `return arr
> + [el]` away, there are still a lot of other mutable methods that you might
> want to use within the reduce closure. So I think the proposal is still
> very valid even if the compiler optimizations would magically appear
> tomorrow.
>
> To push this proposal forward a little bit, I'd like to come up with a
> good name. It seems like we shouldn't overload `reduce`, but choose a
> different name, so that we don't stress the typechecker. Any other
> suggestions?
>
> On Mon, Jan 23, 2017 at 7:11 AM, Russ Bishop  wrote:
> --
> Chris Eidhof
>
>
>
> Sorry for the derail!
>
> reduce(mutating:_:) { } is still my favorite; You can take mutating to
> mean we will copy the value now but mutate it later.
>
>
> Some alternatives:
>
> reduce(forMutating:_:) { }
>
> reduce(forInout:_:) { }
>
> reduce(initial:_:) { }
>
> reduce(copying:mutate:) { }
>
> // just kidding...
> reduce(copyForLaterMutating:_:) { }
>
>
>
> It should definitely be some form of reduce.
>
> Russ
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>


-- 
Chris Eidhof
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Reduce with inout

[Jonathan Hull via swift-evolution]

While we are at it, could we add a inout/mutating version of forEach (unless 
something like that exists and I missed it)?  I have been trying to figure out 
how to run through an array and call a mutating method on each element without 
copying everything, and I am at a loss…

Thanks,
Jon


> On Jan 22, 2017, at 11:27 PM, Russ Bishop via swift-evolution 
>  wrote:
> 
>> 
>> On Jan 22, 2017, at 10:56 PM, Chris Eidhof > > wrote:
>> 
>> Not as a direct reply to Russ, but just to reiterate: to me, there are two 
>> clear benefits of using the `inout` version of reduce:
>> 
>> 1. The performance (currently discussed at length)
>> 2. Readability (because we can use mutating methods on `inout` arguments).
>> 
>> Even if the compiler were to optimize the unnecessary copy of `return arr + 
>> [el]` away, there are still a lot of other mutable methods that you might 
>> want to use within the reduce closure. So I think the proposal is still very 
>> valid even if the compiler optimizations would magically appear tomorrow.
>> 
>> To push this proposal forward a little bit, I'd like to come up with a good 
>> name. It seems like we shouldn't overload `reduce`, but choose a different 
>> name, so that we don't stress the typechecker. Any other suggestions?
>> 
>> On Mon, Jan 23, 2017 at 7:11 AM, Russ Bishop > > wrote:
>> -- 
>> Chris Eidhof
> 
> 
> Sorry for the derail!
> 
> reduce(mutating:_:) { } is still my favorite; You can take mutating to mean 
> we will copy the value now but mutate it later.
> 
> 
> Some alternatives:
> 
> reduce(forMutating:_:) { }
> 
> reduce(forInout:_:) { }
> 
> reduce(initial:_:) { }
> 
> reduce(copying:mutate:) { }
> 
> // just kidding...
> reduce(copyForLaterMutating:_:) { }
> 
> 
> 
> It should definitely be some form of reduce. 
> 
> Russ
> ___
> 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

Re: [swift-evolution] Reduce with inout

[Russ Bishop via swift-evolution]

> On Jan 22, 2017, at 10:56 PM, Chris Eidhof  wrote:
> 
> Not as a direct reply to Russ, but just to reiterate: to me, there are two 
> clear benefits of using the `inout` version of reduce:
> 
> 1. The performance (currently discussed at length)
> 2. Readability (because we can use mutating methods on `inout` arguments).
> 
> Even if the compiler were to optimize the unnecessary copy of `return arr + 
> [el]` away, there are still a lot of other mutable methods that you might 
> want to use within the reduce closure. So I think the proposal is still very 
> valid even if the compiler optimizations would magically appear tomorrow.
> 
> To push this proposal forward a little bit, I'd like to come up with a good 
> name. It seems like we shouldn't overload `reduce`, but choose a different 
> name, so that we don't stress the typechecker. Any other suggestions?
> 
> On Mon, Jan 23, 2017 at 7:11 AM, Russ Bishop  > wrote:
> -- 
> Chris Eidhof


Sorry for the derail!

reduce(mutating:_:) { } is still my favorite; You can take mutating to mean we 
will copy the value now but mutate it later.


Some alternatives:

reduce(forMutating:_:) { }

reduce(forInout:_:) { }

reduce(initial:_:) { }

reduce(copying:mutate:) { }

// just kidding...
reduce(copyForLaterMutating:_:) { }



It should definitely be some form of reduce. 

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

Re: [swift-evolution] Reduce with inout

[Chris Eidhof via swift-evolution]

Not as a direct reply to Russ, but just to reiterate: to me, there are two
clear benefits of using the `inout` version of reduce:

1. The performance (currently discussed at length)
2. Readability (because we can use mutating methods on `inout` arguments).

Even if the compiler were to optimize the unnecessary copy of `return arr +
[el]` away, there are still a lot of other mutable methods that you might
want to use within the reduce closure. So I think the proposal is still
very valid even if the compiler optimizations would magically appear
tomorrow.

To push this proposal forward a little bit, I'd like to come up with a good
name. It seems like we shouldn't overload `reduce`, but choose a different
name, so that we don't stress the typechecker. Any other suggestions?

On Mon, Jan 23, 2017 at 7:11 AM, Russ Bishop  wrote:

>
> On Jan 20, 2017, at 11:27 PM, Charles Srstka 
> wrote:
>
> On Jan 21, 2017, at 12:37 AM, Russ Bishop  wrote:
>
>
> On Jan 16, 2017, at 9:43 AM, Charles Srstka via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> *I don’t even know how long it actually takes to finish this test, because
> the last time I did this I eventually got sick of waiting and killed the
> process. So, I don’t know quite how many orders of magnitude slower it is,
> but it’s a lot.*
>
>
> That’s all the endorsement I need. +1 from me.
>
>
> I do wonder if there is any way to get this sort of optimization out of
> the compiler. I suppose it would be difficult because the compiler doesn’t
> know what the mutable vs immutable pairs are or if such a pair even exists
> (array doesn’t have appending()).
>
>
> The (somewhat naïve) assumption that some optimization of this sort might
> be going on is what led me to do the speed test in the first place.
> However, when you think about it, it’d be really quite hard to do. A reduce
> that builds an array consists of the closure that adds something to an
> array, and the reduce function itself. With the code to both of these, it’s
> not inconceivable that the compiler could figure out what you’re doing, but
> unfortunately the two components live in different modules / compilation
> units. The closure doesn’t know that its return value is just going to be
> replacing the passed-in value, and the reduce function doesn’t know that
> the closure isn’t going to store the original array somewhere, so neither
> can really know that it’s safe to modify the array in place.
>
> Charles
>
>
>
> I was thinking of an optimization like this:
>
> 1. The closure or function doesn’t capture anything (and thus by
> definition nothing can escape the closure)
> 2. ???
> 3. Therefore input returns true for isUniquelyReferenced and no copying of
> the underlying storage is required (Profit!)
>
>
> The problem is obviously in step 2. We don’t have any way to express the
> necessary contract other than inout, which requires a separate definition.
> If it worked like throws/rethrows where a non-mutating closure promoted to
> an inout closure then we could just change the definition of reduce (though
> you’d still have to return the value). The compiler would need to
> understand that ownership of the underlying array storage moves from the
> input parameter to the constructed array inside the closure (and ultimately
> the return value). That’s a bit of a tall order.
>
> That leads me to think about why inout is required (because
> isKnownUniquelyReferenced returns false otherwise). Why can’t the compiler
> determine that the intermediate array is unique? Take this program:
> func doSomething(_ x: MyStruct) -> MyStruct {
> var mutX = x
> let isUnique = isKnownUniquelyReferenced()
> print("isUnique = \(isUnique)") //prints false
> return mutX
> }
> doSomething(MyStruct())
>
>
> The fact that storage is uniquely owned is trivially provable to a human
> but not to the compiler. Why?
>
>
> These are just idle musings. My suspicion is you need ownership
> annotations (aka borrow checker) to make this tractable but I don’t have
> any proof of that.
>
> Russ
>



-- 
Chris Eidhof
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Reduce with inout

[Russ Bishop via swift-evolution]

> On Jan 20, 2017, at 11:27 PM, Charles Srstka  wrote:
> 
>> On Jan 21, 2017, at 12:37 AM, Russ Bishop > > wrote:
>> 
>>> On Jan 16, 2017, at 9:43 AM, Charles Srstka via swift-evolution 
>>> > wrote:
>> 
>>> I don’t even know how long it actually takes to finish this test, because 
>>> the last time I did this I eventually got sick of waiting and killed the 
>>> process. So, I don’t know quite how many orders of magnitude slower it is, 
>>> but it’s a lot.
>> 
>> That’s all the endorsement I need. +1 from me.
>> 
>> 
>> I do wonder if there is any way to get this sort of optimization out of the 
>> compiler. I suppose it would be difficult because the compiler doesn’t know 
>> what the mutable vs immutable pairs are or if such a pair even exists (array 
>> doesn’t have appending()).
> 
> The (somewhat naïve) assumption that some optimization of this sort might be 
> going on is what led me to do the speed test in the first place. However, 
> when you think about it, it’d be really quite hard to do. A reduce that 
> builds an array consists of the closure that adds something to an array, and 
> the reduce function itself. With the code to both of these, it’s not 
> inconceivable that the compiler could figure out what you’re doing, but 
> unfortunately the two components live in different modules / compilation 
> units. The closure doesn’t know that its return value is just going to be 
> replacing the passed-in value, and the reduce function doesn’t know that the 
> closure isn’t going to store the original array somewhere, so neither can 
> really know that it’s safe to modify the array in place.
> 
> Charles



I was thinking of an optimization like this:

1. The closure or function doesn’t capture anything (and thus by definition 
nothing can escape the closure)
2. ???
3. Therefore input returns true for isUniquelyReferenced and no copying of the 
underlying storage is required (Profit!)


The problem is obviously in step 2. We don’t have any way to express the 
necessary contract other than inout, which requires a separate definition. If 
it worked like throws/rethrows where a non-mutating closure promoted to an 
inout closure then we could just change the definition of reduce (though you’d 
still have to return the value). The compiler would need to understand that 
ownership of the underlying array storage moves from the input parameter to the 
constructed array inside the closure (and ultimately the return value). That’s 
a bit of a tall order.

That leads me to think about why inout is required (because 
isKnownUniquelyReferenced returns false otherwise). Why can’t the compiler 
determine that the intermediate array is unique? Take this program:
func doSomething(_ x: MyStruct) -> MyStruct {
var mutX = x
let isUnique = isKnownUniquelyReferenced()
print("isUnique = \(isUnique)") //prints false
return mutX
}
doSomething(MyStruct())


The fact that storage is uniquely owned is trivially provable to a human but 
not to the compiler. Why? 


These are just idle musings. My suspicion is you need ownership annotations 
(aka borrow checker) to make this tractable but I don’t have any proof of that.

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

Re: [swift-evolution] Reduce with inout

[T.J. Usiyan via swift-evolution]

Is there any chance that the forthcoming memory annotations could help
here? If we had some way to signify that the item returned from each call
to the closure should be connected to the incoming argument…

On Sat, Jan 21, 2017 at 2:27 AM, Charles Srstka via swift-evolution <
swift-evolution@swift.org> wrote:

> On Jan 21, 2017, at 12:37 AM, Russ Bishop  wrote:
>
>
> On Jan 16, 2017, at 9:43 AM, Charles Srstka via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> *I don’t even know how long it actually takes to finish this test, because
> the last time I did this I eventually got sick of waiting and killed the
> process. So, I don’t know quite how many orders of magnitude slower it is,
> but it’s a lot.*
>
>
> That’s all the endorsement I need. +1 from me.
>
>
> I do wonder if there is any way to get this sort of optimization out of
> the compiler. I suppose it would be difficult because the compiler doesn’t
> know what the mutable vs immutable pairs are or if such a pair even exists
> (array doesn’t have appending()).
>
>
> The (somewhat naïve) assumption that some optimization of this sort might
> be going on is what led me to do the speed test in the first place.
> However, when you think about it, it’d be really quite hard to do. A reduce
> that builds an array consists of the closure that adds something to an
> array, and the reduce function itself. With the code to both of these, it’s
> not inconceivable that the compiler could figure out what you’re doing, but
> unfortunately the two components live in different modules / compilation
> units. The closure doesn’t know that its return value is just going to be
> replacing the passed-in value, and the reduce function doesn’t know that
> the closure isn’t going to store the original array somewhere, so neither
> can really know that it’s safe to modify the array in place.
>
> Charles
>
>
> ___
> 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

Re: [swift-evolution] Reduce with inout

[Charles Srstka via swift-evolution]

> On Jan 21, 2017, at 12:37 AM, Russ Bishop  wrote:
> 
>> On Jan 16, 2017, at 9:43 AM, Charles Srstka via swift-evolution 
>> > wrote:
> 
>> I don’t even know how long it actually takes to finish this test, because 
>> the last time I did this I eventually got sick of waiting and killed the 
>> process. So, I don’t know quite how many orders of magnitude slower it is, 
>> but it’s a lot.
> 
> That’s all the endorsement I need. +1 from me.
> 
> 
> I do wonder if there is any way to get this sort of optimization out of the 
> compiler. I suppose it would be difficult because the compiler doesn’t know 
> what the mutable vs immutable pairs are or if such a pair even exists (array 
> doesn’t have appending()).

The (somewhat naïve) assumption that some optimization of this sort might be 
going on is what led me to do the speed test in the first place. However, when 
you think about it, it’d be really quite hard to do. A reduce that builds an 
array consists of the closure that adds something to an array, and the reduce 
function itself. With the code to both of these, it’s not inconceivable that 
the compiler could figure out what you’re doing, but unfortunately the two 
components live in different modules / compilation units. The closure doesn’t 
know that its return value is just going to be replacing the passed-in value, 
and the reduce function doesn’t know that the closure isn’t going to store the 
original array somewhere, so neither can really know that it’s safe to modify 
the array in place.

Charles

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

Re: [swift-evolution] Reduce with inout

[Georgios Moschovitis via swift-evolution]

> 
>> On 18 Jan 2017, at 12:45, Georgios Moschovitis 
>>  wrote:
>> 
>>> That’s what I thought also until just now, but then why wouldn’t you just 
>>> use a for …  in loop?
>> 
>> the former gives a hint about what someFunction (and the for-loop) is doing.
> 
> 
> Whereas the latter explicitly lays out what is happening.

But, you have to actually read the loop to understand that it *is* reducing.
In this simple case, it’s obvious, but for more complex reduction, the ‘hint’ 
can be useful.

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

Re: [swift-evolution] Reduce with inout

[Russ Bishop via swift-evolution]

> On Jan 16, 2017, at 9:43 AM, Charles Srstka via swift-evolution 
>  wrote:

> I don’t even know how long it actually takes to finish this test, because the 
> last time I did this I eventually got sick of waiting and killed the process. 
> So, I don’t know quite how many orders of magnitude slower it is, but it’s a 
> lot.

That’s all the endorsement I need. +1 from me.


I do wonder if there is any way to get this sort of optimization out of the 
compiler. I suppose it would be difficult because the compiler doesn’t know 
what the mutable vs immutable pairs are or if such a pair even exists (array 
doesn’t have appending()).

If we assume + for Array had a mutating variant ala func + (lhs: inout Array, 
rhs: Array) { … }, would the compiler be able to prefer the inout version? What 
if a type wanted to offer a specialized version of a function for the compiler 
to call when the compiler can prove only temporaries are involved? I don’t want 
to go too far down the road of move constructors and whatnot for that way lies 
madness.


(Not a compiler expert, just wondering if there is a way to make situations 
like this into a “pit of success”).

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

Re: [swift-evolution] Reduce with inout

[Jeremy Pereira via swift-evolution]

> On 18 Jan 2017, at 12:45, Georgios Moschovitis 
>  wrote:
> 
>> That’s what I thought also until just now, but then why wouldn’t you just 
>> use a for …  in loop?
> 
> the former gives a hint about what someFunction (and the for-loop) is doing.


Whereas the latter explicitly lays out what is happening.

> 
> -g.

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

Re: [swift-evolution] Reduce with inout

[Tony Allevato via swift-evolution]

On Wed, Jan 18, 2017 at 10:33 AM Guillaume Lessard via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On 18 janv. 2017, at 10:21, Joe Groff via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >> On Jan 18, 2017, at 2:11 AM, Chris Eidhof via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> If stressing the type-checker is the only problem, then maybe we should
> improve the type-checker, instead of placing that burden on every user of
> the language.
> >
> > That's a nice sentiment, and there's certainly a lot of work we have yet
> to do on the type checker to make it generally better. Higher-order
> functions like `reduce` naturally chain into larger expressions, though,
> and having such a fundamental sequence operation drag down the type-checker
> every time you use it would be unfortunate if we can avoid overloading the
> name.
>
> Empathy for the compiler is nice, too, but users and developers are more
> important. Given that, it seems to me that the default option should be to
> overload the function, unless the alternative is actually clearer.
>

Empathy for users and developers is important, but if the solution adds too
much burden to the type checker and blows up your compile time or gives you
"expression too complex to be solved" errors, then users/developers don't
benefit at all from that either. I don't think it would have been brought
up if there weren't significant concerns about how such an overload would
affect build time or ability to complete. (One of my code bases really
pushes the type checker to its limits and I can sympathize with the
concern.)



> In the spirit of comparing burdens, how much more compilation time would
> be spent if `reduce` is overloaded? How much execution time would be saved
> by users thanks to developers having found the right option?
>
> This being said, it seems to me that the example that started this
> discussion (building a collection) is among the worst-performing cases for
> the functional-style `reduce`. What are other cases where the inout version
> is a big win? If this is specifically about building collections or
> sequences, could a more specific type signature help?
>
> Arguing both for and against,
> Guillaume Lessard
>
> ___
> 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

Re: [swift-evolution] Reduce with inout

[Guillaume Lessard via swift-evolution]

> On 18 janv. 2017, at 10:21, Joe Groff via swift-evolution 
>  wrote:
> 
>> On Jan 18, 2017, at 2:11 AM, Chris Eidhof via swift-evolution 
>>  wrote:
>> 
>> If stressing the type-checker is the only problem, then maybe we should 
>> improve the type-checker, instead of placing that burden on every user of 
>> the language.
> 
> That's a nice sentiment, and there's certainly a lot of work we have yet to 
> do on the type checker to make it generally better. Higher-order functions 
> like `reduce` naturally chain into larger expressions, though, and having 
> such a fundamental sequence operation drag down the type-checker every time 
> you use it would be unfortunate if we can avoid overloading the name.

Empathy for the compiler is nice, too, but users and developers are more 
important. Given that, it seems to me that the default option should be to 
overload the function, unless the alternative is actually clearer.

In the spirit of comparing burdens, how much more compilation time would be 
spent if `reduce` is overloaded? How much execution time would be saved by 
users thanks to developers having found the right option?

This being said, it seems to me that the example that started this discussion 
(building a collection) is among the worst-performing cases for the 
functional-style `reduce`. What are other cases where the inout version is a 
big win? If this is specifically about building collections or sequences, could 
a more specific type signature help?

Arguing both for and against,
Guillaume Lessard

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

Re: [swift-evolution] Reduce with inout

[Joe Groff via swift-evolution]

> On Jan 18, 2017, at 2:11 AM, Chris Eidhof via swift-evolution 
>  wrote:
> 
> I don't think we should replace the current `reduce` with the `inout` 
> version, also because the current reduce can be really useful as well (e.g. 
> when the return type is an Int). 
> 
> One downside of having a different name is that it'll be harder to discover 
> this version. If stressing the type-checker is the only problem, then maybe 
> we should improve the type-checker, instead of placing that burden on every 
> user of the language.

That's a nice sentiment, and there's certainly a lot of work we have yet to do 
on the type checker to make it generally better. Higher-order functions like 
`reduce` naturally chain into larger expressions, though, and having such a 
fundamental sequence operation drag down the type-checker every time you use it 
would be unfortunate if we can avoid overloading the name.

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

Re: [swift-evolution] Reduce with inout

[Chris Eidhof via swift-evolution]

I think the nice thing about reduce is that you can use it to implement
something in a single line, and directly return it. Making the first
parameter inout would require you to write `var result = ` and `return
result` (and `result` will be mutable after the call to `reduce`).
Typically, the initial value is some kind of empty value, so copying isn't
a problem. In my usage, making the first parameter inout would make the
code more verbose, decrease readability and not win too much.

I think that making initialValue an inout is a cool idea, but I don't think
it's something for this proposal. (I'm open for good arguments, though).

On Wed, Jan 18, 2017 at 1:48 PM, Georgios Moschovitis via swift-evolution <
swift-evolution@swift.org> wrote:

> the former gives a hint about what someFunction (and the for-loop) is
> doing.
>
> -g.
>
> > On 18 Jan 2017, at 2:32 PM, Jeremy Pereira via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> >> On 18 Jan 2017, at 12:26, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> Thought: if the idea is performance and not drop-in replacement, why
> force the user to incur two copies? If the initial value were inout, this
> function would be more unambiguous even without a new name, and at _worst_
> the user has to declare a variable with var, a worthwhile trade-off to save
> two copies.
> >
> > That’s what I thought also until just now, but then why wouldn’t you
> just use a for …  in loop?
> >
> > i.e. instead of
> >
> >var foo = 0
> >let bar: [SomeType] = ...
> >
> >bar.reduce(mutating: , someFunction)
> >
> > You would write
> >
> >var foo = 0
> >let bar: [SomeType] = …
> >
> >for e in bar {
> >someFunction(, e)
> >}
> >
> > which is a bit more readable IMO
> > ___
> > 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
>



-- 
Chris Eidhof
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Reduce with inout

[Georgios Moschovitis via swift-evolution]

the former gives a hint about what someFunction (and the for-loop) is doing.

-g.

> On 18 Jan 2017, at 2:32 PM, Jeremy Pereira via swift-evolution 
>  wrote:
> 
> 
>> On 18 Jan 2017, at 12:26, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> Thought: if the idea is performance and not drop-in replacement, why force 
>> the user to incur two copies? If the initial value were inout, this function 
>> would be more unambiguous even without a new name, and at _worst_ the user 
>> has to declare a variable with var, a worthwhile trade-off to save two 
>> copies.
> 
> That’s what I thought also until just now, but then why wouldn’t you just use 
> a for …  in loop?
> 
> i.e. instead of
> 
>var foo = 0
>let bar: [SomeType] = ...
> 
>bar.reduce(mutating: , someFunction) 
> 
> You would write
> 
>var foo = 0
>let bar: [SomeType] = …
> 
>for e in bar {
>someFunction(, e)
>}
> 
> which is a bit more readable IMO
> ___
> 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

Re: [swift-evolution] Reduce with inout

[Jeremy Pereira via swift-evolution]

> On 18 Jan 2017, at 12:26, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Thought: if the idea is performance and not drop-in replacement, why force 
> the user to incur two copies? If the initial value were inout, this function 
> would be more unambiguous even without a new name, and at _worst_ the user 
> has to declare a variable with var, a worthwhile trade-off to save two copies.

That’s what I thought also until just now, but then why wouldn’t you just use a 
for …  in loop?

i.e. instead of

var foo = 0
let bar: [SomeType] = ...

bar.reduce(mutating: , someFunction) 

You would write

var foo = 0
let bar: [SomeType] = …

for e in bar {
someFunction(, e)
}

which is a bit more readable IMO
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Reduce with inout

[Xiaodi Wu via swift-evolution]

Thought: if the idea is performance and not drop-in replacement, why force
the user to incur two copies? If the initial value were inout, this
function would be more unambiguous even without a new name, and at _worst_
the user has to declare a variable with var, a worthwhile trade-off to save
two copies.

(Ack, Jeremy just beat me to it!)
On Wed, Jan 18, 2017 at 05:45 Chris Eidhof via swift-evolution <
swift-evolution@swift.org> wrote:

> I opened up a WIP PR on the SE repository (so many TLA's!).
> https://github.com/apple/swift-evolution/pull/587
>
> I think I'll wait a few days before removing `WIP` until the naming
> discussion either reaches consensus or settles down.
>
> So far, I would summarize the thread as: people are in favor, but there is
> disagreement on the naming. I suspect the core team will ultimately decide
> on the naming?
>
> On Wed, Jan 18, 2017 at 11:11 AM, Chris Eidhof  wrote:
>
> I don't think we should replace the current `reduce` with the `inout`
> version, also because the current reduce can be really useful as well (e.g.
> when the return type is an Int).
>
> One downside of having a different name is that it'll be harder to
> discover this version. If stressing the type-checker is the only problem,
> then maybe we should improve the type-checker, instead of placing that
> burden on every user of the language.
>
>
>
> On Wed, Jan 18, 2017 at 9:36 AM, Karl Wagner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 18 Jan 2017, at 09:00, Anton Zhilin via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> While realizing that this name can cause confusion, I'd still prefer
> `reduce(mutating:_:)`, because it looks like the only readable option to me.
> Whatever name will be picked, I agree that traditional reduce without
> mutation should retain its name.
>
> 2017-01-18 5:17 GMT+03:00 Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org>:
>
> A serious possibility would be: `reduce(mutableCopyOf: x) { ... }`.
>
> It's verbose, but the nicer-looking `reduce(mutating: x) { ... }` is
> incorrect since, as Charles pointed out to Dave, it's not `x` that's
> mutated but rather a mutable copy of it, so it doesn't matter if `x` itself
> is declared with `let` or `var`.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> I suppose as a second-choice I’d go for accumulate(into: with:):
>
> [1, 2, 3].accumulate(into: 0, with: +=)
>
> even [1, 2, 3].accumulate(into: 0, with: -=) doesn’t look so bad IMO.
>
> - Karl
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
> --
> Chris Eidhof
>
>
>
>
> --
> Chris Eidhof
> ___
> 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

Re: [swift-evolution] Reduce with inout

[Jeremy Pereira via swift-evolution]

> On 18 Jan 2017, at 02:17, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> A serious possibility would be: `reduce(mutableCopyOf: x) { ... }`.
> 
> It's verbose, but the nicer-looking `reduce(mutating: x) { ... }` is 
> incorrect since, as Charles pointed out to Dave, it's not `x` that's mutated 
> but rather a mutable copy of it, so it doesn't matter if `x` itself is 
> declared with `let` or `var`.

Why not also have that version?

var foo = 0
let bar: [SomeType] = ...

bar.reduce(mutating: , someFunction) 

// foo now contains the reduced bar


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

Re: [swift-evolution] Reduce with inout

[Chris Eidhof via swift-evolution]

I opened up a WIP PR on the SE repository (so many TLA's!).
https://github.com/apple/swift-evolution/pull/587

I think I'll wait a few days before removing `WIP` until the naming
discussion either reaches consensus or settles down.

So far, I would summarize the thread as: people are in favor, but there is
disagreement on the naming. I suspect the core team will ultimately decide
on the naming?

On Wed, Jan 18, 2017 at 11:11 AM, Chris Eidhof  wrote:

> I don't think we should replace the current `reduce` with the `inout`
> version, also because the current reduce can be really useful as well (e.g.
> when the return type is an Int).
>
> One downside of having a different name is that it'll be harder to
> discover this version. If stressing the type-checker is the only problem,
> then maybe we should improve the type-checker, instead of placing that
> burden on every user of the language.
>
>
>
> On Wed, Jan 18, 2017 at 9:36 AM, Karl Wagner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On 18 Jan 2017, at 09:00, Anton Zhilin via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> While realizing that this name can cause confusion, I'd still prefer
>> `reduce(mutating:_:)`, because it looks like the only readable option to me.
>> Whatever name will be picked, I agree that traditional reduce without
>> mutation should retain its name.
>>
>> 2017-01-18 5:17 GMT+03:00 Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org>:
>>
>>> A serious possibility would be: `reduce(mutableCopyOf: x) { ... }`.
>>>
>>> It's verbose, but the nicer-looking `reduce(mutating: x) { ... }` is
>>> incorrect since, as Charles pointed out to Dave, it's not `x` that's
>>> mutated but rather a mutable copy of it, so it doesn't matter if `x` itself
>>> is declared with `let` or `var`.
>>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> I suppose as a second-choice I’d go for accumulate(into: with:):
>>
>> [1, 2, 3].accumulate(into: 0, with: +=)
>>
>> even [1, 2, 3].accumulate(into: 0, with: -=) doesn’t look so bad IMO.
>>
>> - Karl
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
>
> --
> Chris Eidhof
>



-- 
Chris Eidhof
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Reduce with inout

[Chris Eidhof via swift-evolution]

I don't think we should replace the current `reduce` with the `inout`
version, also because the current reduce can be really useful as well (e.g.
when the return type is an Int).

One downside of having a different name is that it'll be harder to discover
this version. If stressing the type-checker is the only problem, then maybe
we should improve the type-checker, instead of placing that burden on every
user of the language.



On Wed, Jan 18, 2017 at 9:36 AM, Karl Wagner via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On 18 Jan 2017, at 09:00, Anton Zhilin via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> While realizing that this name can cause confusion, I'd still prefer
> `reduce(mutating:_:)`, because it looks like the only readable option to me.
> Whatever name will be picked, I agree that traditional reduce without
> mutation should retain its name.
>
> 2017-01-18 5:17 GMT+03:00 Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org>:
>
>> A serious possibility would be: `reduce(mutableCopyOf: x) { ... }`.
>>
>> It's verbose, but the nicer-looking `reduce(mutating: x) { ... }` is
>> incorrect since, as Charles pointed out to Dave, it's not `x` that's
>> mutated but rather a mutable copy of it, so it doesn't matter if `x` itself
>> is declared with `let` or `var`.
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> I suppose as a second-choice I’d go for accumulate(into: with:):
>
> [1, 2, 3].accumulate(into: 0, with: +=)
>
> even [1, 2, 3].accumulate(into: 0, with: -=) doesn’t look so bad IMO.
>
> - Karl
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
Chris Eidhof
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Reduce with inout

[Karl Wagner via swift-evolution]

> On 18 Jan 2017, at 09:00, Anton Zhilin via swift-evolution 
>  wrote:
> 
> While realizing that this name can cause confusion, I'd still prefer 
> `reduce(mutating:_:)`, because it looks like the only readable option to me.
> Whatever name will be picked, I agree that traditional reduce without 
> mutation should retain its name.
> 
> 2017-01-18 5:17 GMT+03:00 Xiaodi Wu via swift-evolution 
> >:
> A serious possibility would be: `reduce(mutableCopyOf: x) { ... }`.
> 
> It's verbose, but the nicer-looking `reduce(mutating: x) { ... }` is 
> incorrect since, as Charles pointed out to Dave, it's not `x` that's mutated 
> but rather a mutable copy of it, so it doesn't matter if `x` itself is 
> declared with `let` or `var`. 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

I suppose as a second-choice I’d go for accumulate(into: with:):

[1, 2, 3].accumulate(into: 0, with: +=) 

even [1, 2, 3].accumulate(into: 0, with: -=) doesn’t look so bad IMO.

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

Re: [swift-evolution] Reduce with inout

[Anton Zhilin via swift-evolution]

While realizing that this name can cause confusion, I'd still prefer
`reduce(mutating:_:)`, because it looks like the only readable option to me.
Whatever name will be picked, I agree that traditional reduce without
mutation should retain its name.

2017-01-18 5:17 GMT+03:00 Xiaodi Wu via swift-evolution <
swift-evolution@swift.org>:

> A serious possibility would be: `reduce(mutableCopyOf: x) { ... }`.
>
> It's verbose, but the nicer-looking `reduce(mutating: x) { ... }` is
> incorrect since, as Charles pointed out to Dave, it's not `x` that's
> mutated but rather a mutable copy of it, so it doesn't matter if `x` itself
> is declared with `let` or `var`.
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Reduce with inout

[Pranshu Goyal via swift-evolution]

What about `reducing(x, combine: {...})`

On 18 January 2017 at 07:47, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> A serious possibility would be: `reduce(mutableCopyOf: x) { ... }`.
>
> It's verbose, but the nicer-looking `reduce(mutating: x) { ... }` is
> incorrect since, as Charles pointed out to Dave, it's not `x` that's
> mutated but rather a mutable copy of it, so it doesn't matter if `x` itself
> is declared with `let` or `var`.
>
>
> On Tue, Jan 17, 2017 at 7:46 PM, Sean Heber  wrote:
>
>> `reuse`
>>
>> Then we just need an excuse for a function named ‘recycle’...
>>
>> l8r
>> Sean
>>
>>
>> > On Jan 17, 2017, at 7:36 PM, T.J. Usiyan via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> > `reduceInout`
>> >
>> > On Tue, Jan 17, 2017 at 6:30 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> > Agree. The functional style should keep the functional name.
>> >
>> > On Tue, Jan 17, 2017 at 16:18 David Sweeris via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> > On Jan 17, 2017, at 16:11, Karl Wagner via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> >>
>> >>> On 17 Jan 2017, at 23:09, Karl Wagner 
>> wrote:
>> >>>
>> >>>
>>  On 16 Jan 2017, at 14:49, Chris Eidhof via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> 
>>  Hi,
>> 
>>  How does everyone feel about adding a second version of `reduce` to
>> `Sequence`? Instead of a `combine` function that's of type `(A, Element) ->
>> A`, it would be `(inout A, Element) -> ()`. This way, we can write nice
>> functionals algorithms, but have the benefits of inout (mutation within the
>> function, and hopefully some copy eliminations).
>> 
>>  IIRC, Loïc Lecrenier first asked this on Twitter. I've been using it
>> ever since, because it can really improve readability (the possible
>> performance gain is nice, too).
>> 
>>  Here's `reduce` with an `inout` parameter, including a sample:
>> https://gist.github.com/chriseidhof/fd3e9aa621569752d1b04230f92969d7
>> 
>>  --
>>  Chris Eidhof
>>  ___
>>  swift-evolution mailing list
>>  swift-evolution@swift.org
>>  https://lists.swift.org/mailman/listinfo/swift-evolution
>> >>>
>> >>> +1
>> >>>
>> >>> I would even argue for it to be the default.
>> >>
>> >> I mean, assuming having two “reduce”s would stress the typechecker, as
>> Joe suggested it might, I would say “inout” makes sense to be the default
>> and the other one can find itself a new name.
>> >
>> > IIRC, the "reduce" name comes from functional programming... should the
>> functional style keep the functional name?
>> >
>> > - Dave Sweeris
>> > ___
>> > 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
>
>


-- 
*Pranshu Goyal*
*iOS Developer*
*tlkn*
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Reduce with inout

[Xiaodi Wu via swift-evolution]

A serious possibility would be: `reduce(mutableCopyOf: x) { ... }`.

It's verbose, but the nicer-looking `reduce(mutating: x) { ... }` is
incorrect since, as Charles pointed out to Dave, it's not `x` that's
mutated but rather a mutable copy of it, so it doesn't matter if `x` itself
is declared with `let` or `var`.


On Tue, Jan 17, 2017 at 7:46 PM, Sean Heber  wrote:

> `reuse`
>
> Then we just need an excuse for a function named ‘recycle’...
>
> l8r
> Sean
>
>
> > On Jan 17, 2017, at 7:36 PM, T.J. Usiyan via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > `reduceInout`
> >
> > On Tue, Jan 17, 2017 at 6:30 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
> > Agree. The functional style should keep the functional name.
> >
> > On Tue, Jan 17, 2017 at 16:18 David Sweeris via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > On Jan 17, 2017, at 16:11, Karl Wagner via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >>
> >>> On 17 Jan 2017, at 23:09, Karl Wagner 
> wrote:
> >>>
> >>>
>  On 16 Jan 2017, at 14:49, Chris Eidhof via swift-evolution <
> swift-evolution@swift.org> wrote:
> 
>  Hi,
> 
>  How does everyone feel about adding a second version of `reduce` to
> `Sequence`? Instead of a `combine` function that's of type `(A, Element) ->
> A`, it would be `(inout A, Element) -> ()`. This way, we can write nice
> functionals algorithms, but have the benefits of inout (mutation within the
> function, and hopefully some copy eliminations).
> 
>  IIRC, Loïc Lecrenier first asked this on Twitter. I've been using it
> ever since, because it can really improve readability (the possible
> performance gain is nice, too).
> 
>  Here's `reduce` with an `inout` parameter, including a sample:
> https://gist.github.com/chriseidhof/fd3e9aa621569752d1b04230f92969d7
> 
>  --
>  Chris Eidhof
>  ___
>  swift-evolution mailing list
>  swift-evolution@swift.org
>  https://lists.swift.org/mailman/listinfo/swift-evolution
> >>>
> >>> +1
> >>>
> >>> I would even argue for it to be the default.
> >>
> >> I mean, assuming having two “reduce”s would stress the typechecker, as
> Joe suggested it might, I would say “inout” makes sense to be the default
> and the other one can find itself a new name.
> >
> > IIRC, the "reduce" name comes from functional programming... should the
> functional style keep the functional name?
> >
> > - Dave Sweeris
> > ___
> > 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

Re: [swift-evolution] Reduce with inout

[Sean Heber via swift-evolution]

`reuse`

Then we just need an excuse for a function named ‘recycle’...

l8r
Sean


> On Jan 17, 2017, at 7:36 PM, T.J. Usiyan via swift-evolution 
>  wrote:
> 
> `reduceInout`
> 
> On Tue, Jan 17, 2017 at 6:30 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> Agree. The functional style should keep the functional name.
> 
> On Tue, Jan 17, 2017 at 16:18 David Sweeris via swift-evolution 
>  wrote:
> 
> On Jan 17, 2017, at 16:11, Karl Wagner via swift-evolution 
>  wrote:
> 
>> 
>>> On 17 Jan 2017, at 23:09, Karl Wagner  wrote:
>>> 
>>> 
 On 16 Jan 2017, at 14:49, Chris Eidhof via swift-evolution 
  wrote:
 
 Hi,
 
 How does everyone feel about adding a second version of `reduce` to 
 `Sequence`? Instead of a `combine` function that's of type `(A, Element) 
 -> A`, it would be `(inout A, Element) -> ()`. This way, we can write nice 
 functionals algorithms, but have the benefits of inout (mutation within 
 the function, and hopefully some copy eliminations).
 
 IIRC, Loïc Lecrenier first asked this on Twitter. I've been using it ever 
 since, because it can really improve readability (the possible performance 
 gain is nice, too).
 
 Here's `reduce` with an `inout` parameter, including a sample: 
 https://gist.github.com/chriseidhof/fd3e9aa621569752d1b04230f92969d7
 
 -- 
 Chris Eidhof
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> +1
>>> 
>>> I would even argue for it to be the default.
>> 
>> I mean, assuming having two “reduce”s would stress the typechecker, as Joe 
>> suggested it might, I would say “inout” makes sense to be the default and 
>> the other one can find itself a new name. 
> 
> IIRC, the "reduce" name comes from functional programming... should the 
> functional style keep the functional name?
> 
> - Dave Sweeris 
> ___
> 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

Re: [swift-evolution] Reduce with inout

[T.J. Usiyan via swift-evolution]

`reduceInout`

On Tue, Jan 17, 2017 at 6:30 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> Agree. The functional style should keep the functional name.
>
> On Tue, Jan 17, 2017 at 16:18 David Sweeris via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On Jan 17, 2017, at 16:11, Karl Wagner via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> On 17 Jan 2017, at 23:09, Karl Wagner  wrote:
>>
>>
>> On 16 Jan 2017, at 14:49, Chris Eidhof via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Hi,
>>
>> How does everyone feel about adding a second version of `reduce` to
>> `Sequence`? Instead of a `combine` function that's of type `(A, Element) ->
>> A`, it would be `(inout A, Element) -> ()`. This way, we can write nice
>> functionals algorithms, but have the benefits of inout (mutation within the
>> function, and hopefully some copy eliminations).
>>
>> IIRC, Loïc Lecrenier first asked this on Twitter. I've been using it ever
>> since, because it can really improve readability (the possible performance
>> gain is nice, too).
>>
>> Here's `reduce` with an `inout` parameter, including a sample:
>> https://gist.github.com/chriseidhof/fd3e9aa621569752d1b04230f92969d7
>>
>> --
>> Chris Eidhof
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> +1
>>
>> I would even argue for it to be the default.
>>
>>
>> I mean, assuming having two “reduce”s would stress the typechecker, as
>> Joe suggested it might, I would say “inout” makes sense to be the default
>> and the other one can find itself a new name.
>>
>>
>> IIRC, the "reduce" name comes from functional programming... should the
>> functional style keep the functional name?
>>
>> - Dave Sweeris
>> ___
>> 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

Re: [swift-evolution] Reduce with inout

[Xiaodi Wu via swift-evolution]

Agree. The functional style should keep the functional name.
On Tue, Jan 17, 2017 at 16:18 David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jan 17, 2017, at 16:11, Karl Wagner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 17 Jan 2017, at 23:09, Karl Wagner  wrote:
>
>
> On 16 Jan 2017, at 14:49, Chris Eidhof via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi,
>
> How does everyone feel about adding a second version of `reduce` to
> `Sequence`? Instead of a `combine` function that's of type `(A, Element) ->
> A`, it would be `(inout A, Element) -> ()`. This way, we can write nice
> functionals algorithms, but have the benefits of inout (mutation within the
> function, and hopefully some copy eliminations).
>
> IIRC, Loïc Lecrenier first asked this on Twitter. I've been using it ever
> since, because it can really improve readability (the possible performance
> gain is nice, too).
>
> Here's `reduce` with an `inout` parameter, including a sample:
> https://gist.github.com/chriseidhof/fd3e9aa621569752d1b04230f92969d7
>
> --
> Chris Eidhof
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> +1
>
> I would even argue for it to be the default.
>
>
> I mean, assuming having two “reduce”s would stress the typechecker, as Joe
> suggested it might, I would say “inout” makes sense to be the default and
> the other one can find itself a new name.
>
>
> IIRC, the "reduce" name comes from functional programming... should the
> functional style keep the functional name?
>
> - Dave Sweeris
> ___
> 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

Re: [swift-evolution] Reduce with inout

[David Sweeris via swift-evolution]

> On Jan 17, 2017, at 16:11, Karl Wagner via swift-evolution 
>  wrote:
> 
> 
>>> On 17 Jan 2017, at 23:09, Karl Wagner  wrote:
>>> 
>>> 
>>> On 16 Jan 2017, at 14:49, Chris Eidhof via swift-evolution 
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>> How does everyone feel about adding a second version of `reduce` to 
>>> `Sequence`? Instead of a `combine` function that's of type `(A, Element) -> 
>>> A`, it would be `(inout A, Element) -> ()`. This way, we can write nice 
>>> functionals algorithms, but have the benefits of inout (mutation within the 
>>> function, and hopefully some copy eliminations).
>>> 
>>> IIRC, Loïc Lecrenier first asked this on Twitter. I've been using it ever 
>>> since, because it can really improve readability (the possible performance 
>>> gain is nice, too).
>>> 
>>> Here's `reduce` with an `inout` parameter, including a sample: 
>>> https://gist.github.com/chriseidhof/fd3e9aa621569752d1b04230f92969d7
>>> 
>>> -- 
>>> Chris Eidhof
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> +1
>> 
>> I would even argue for it to be the default.
> 
> I mean, assuming having two “reduce”s would stress the typechecker, as Joe 
> suggested it might, I would say “inout” makes sense to be the default and the 
> other one can find itself a new name. 

IIRC, the "reduce" name comes from functional programming... should the 
functional style keep the functional name?

- Dave Sweeris ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Reduce with inout

[Karl Wagner via swift-evolution]

> On 17 Jan 2017, at 23:09, Karl Wagner  wrote:
> 
> 
>> On 16 Jan 2017, at 14:49, Chris Eidhof via swift-evolution 
>> > wrote:
>> 
>> Hi,
>> 
>> How does everyone feel about adding a second version of `reduce` to 
>> `Sequence`? Instead of a `combine` function that's of type `(A, Element) -> 
>> A`, it would be `(inout A, Element) -> ()`. This way, we can write nice 
>> functionals algorithms, but have the benefits of inout (mutation within the 
>> function, and hopefully some copy eliminations).
>> 
>> IIRC, Loïc Lecrenier first asked this on Twitter. I've been using it ever 
>> since, because it can really improve readability (the possible performance 
>> gain is nice, too).
>> 
>> Here's `reduce` with an `inout` parameter, including a sample: 
>> https://gist.github.com/chriseidhof/fd3e9aa621569752d1b04230f92969d7 
>> 
>> 
>> -- 
>> Chris Eidhof
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> +1
> 
> I would even argue for it to be the default.

I mean, assuming having two “reduce”s would stress the typechecker, as Joe 
suggested it might, I would say “inout” makes sense to be the default and the 
other one can find itself a new name. ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Reduce with inout

[Karl Wagner via swift-evolution]

> On 16 Jan 2017, at 14:49, Chris Eidhof via swift-evolution 
>  wrote:
> 
> Hi,
> 
> How does everyone feel about adding a second version of `reduce` to 
> `Sequence`? Instead of a `combine` function that's of type `(A, Element) -> 
> A`, it would be `(inout A, Element) -> ()`. This way, we can write nice 
> functionals algorithms, but have the benefits of inout (mutation within the 
> function, and hopefully some copy eliminations).
> 
> IIRC, Loïc Lecrenier first asked this on Twitter. I've been using it ever 
> since, because it can really improve readability (the possible performance 
> gain is nice, too).
> 
> Here's `reduce` with an `inout` parameter, including a sample: 
> https://gist.github.com/chriseidhof/fd3e9aa621569752d1b04230f92969d7 
> 
> 
> -- 
> Chris Eidhof
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

+1

I would even argue for it to be the default.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Reduce with inout

[Ben Cohen via swift-evolution]

> On Jan 16, 2017, at 5:49 AM, Chris Eidhof via swift-evolution 
>  wrote:
> 
> Hi,
> 
> How does everyone feel about adding a second version of `reduce` to 
> `Sequence`? Instead of a `combine` function that's of type `(A, Element) -> 
> A`, it would be `(inout A, Element) -> ()`. This way, we can write nice 
> functionals algorithms, but have the benefits of inout (mutation within the 
> function, and hopefully some copy eliminations).
> 
> IIRC, Loïc Lecrenier first asked this on Twitter. I've been using it ever 
> since, because it can really improve readability (the possible performance 
> gain is nice, too).
> 
> Here's `reduce` with an `inout` parameter, including a sample: 
> https://gist.github.com/chriseidhof/fd3e9aa621569752d1b04230f92969d7 
> 
> 
> -- 
> Chris Eidhof
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

+1

Instead of a filter reimplementation for the proposal, might be good to do 
something that doesn’t exist this would be useful for, like a version of Unix 
uniq that filters adjacent equal entries.


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

Re: [swift-evolution] Reduce with inout

[Joe Groff via swift-evolution]

> On Jan 17, 2017, at 11:52 AM, Chris Eidhof  wrote:
> 
> Any arguments against adding it? Otherwise I'll draft up a short proposal 
> tomorrow.

I think it's the right thing for Swift. My main concern would be naming. If 
they're both named `reduce`, I suspect that will stress the type checker trying 
to pick an overload based on the context of the closure expression. We're stuck 
with `reduce` having the value-in-return-out formulation for Swift 3 
compatibility; if that weren't the case, I'd argue we only need the `inout` 
form.

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

Re: [swift-evolution] Reduce with inout

[Chris Eidhof via swift-evolution]

Any arguments against adding it? Otherwise I'll draft up a short proposal
tomorrow.

On Tue, Jan 17, 2017 at 7:24 PM, Joe Groff via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jan 16, 2017, at 8:10 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> > on Mon Jan 16 2017, Charles Srstka  wrote:
> >
> >> On Jan 16, 2017, at 6:42 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>>
> >>>
> >>> on Mon Jan 16 2017, Charles Srstka  >>> > wrote:
> >>>
> >>
> > On Jan 16, 2017, at 7:49 AM, Chris Eidhof via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Hi,
> >
> > How does everyone feel about adding a second version of `reduce` to
> 
> > `Sequence`? Instead of a `combine` function that's of type `(A,
> > Element) -> A`, it would be `(inout A, Element) -> ()`. This way, we
> > can write nice functionals algorithms, but have the benefits of
> > inout (mutation within the function, and hopefully some copy
> > eliminations).
> >
> > IIRC, Loïc Lecrenier first asked this on Twitter. I've been using it
> > ever since, because it can really improve readability (the possible
> > performance gain is nice, too).
> >
> > Here's `reduce` with an `inout` parameter, including a sample:
> > https://gist.github.com/chriseidhof/fd3e9aa621569752d1b04230f92969d7
> >
> > --
> > Chris Eidhof
> 
>  I did this in my own private code a while ago. There is one drawback,
> which is that Swift’s type
>  inference system isn’t quite up to handling it. For example, doing
> this results in an “ambiguous
>  reference to member” warning:
> 
>  range.reduce([Int]()) { $0.append($1) }
> >>>
> >>> The diagnostic could be better, but the compiler shouldn't let you do
> >>> that, because it requires passing an unnamed temporary value ([Int]())
> >>> as inout.
> >>
> >> No it doesn’t. The signature of the method is:
> >>
> >> func reduce(_ initial: A, combine: (inout A, Iterator.Element) ->
> ()) -> A
> >>
> >> The unnamed temporary value is “initial” here, which is not passed as
> inout; the inout parameter is
> >> the first argument to the “combine” closure. The value represented by
> the ‘initial’ parameter is
> >> passed to the closure, true, but only after being stored in a
> not-unnamed ‘var’ variable, as you can
> >> see from the source of the proposed method:
> >>
> >> func reduce(_ initial: A, combine: (inout A, Iterator.Element) ->
> ()) -> A {
> >>var result = initial
> >>for element in self {
> >>combine(, element)
> >>}
> >>return result
> >> }
> >>
> >> Therefore, I don’t understand this objection.
> >>
>  One would think that the type of this closure should be clear:
> 
>  1) The closure calls append(), a mutating function, so $0 must be
> inout.
> 
>  2) The closure doesn’t return anything, which should rule out the
>  default implementations of reduce,
> >>>
> >>> The closure *does* return something: (), the empty tuple
> >>
> >> But it’s not what it’s supposed to return. Sequence’s implementation
> >> of reduce, which the compiler thinks matches the above, is declared
> >> like this:
> >>
> >> public func reduce(_ initialResult: Result, _
> >> nextPartialResult: (Result, Self.Iterator.Element) throws -> Result)
> >> rethrows -> Result
> >>
> >> The closure is supposed to return Result, which in this case would be
> >> [Int]. It doesn’t, so I’m not sure why the compiler is thinking this
> >> is a match.
> >
> > Okay, sounds like I'm totally wrong! Has to happen at least once in a
> > lifetime, doesn't it? 
> >
> > So please file bug reports for these issues.
>
> This one should already be fixed in master. If it isn't, definitely file a
> new one!
>
> -Joe
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
Chris Eidhof
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Reduce with inout

[Joe Groff via swift-evolution]

> On Jan 16, 2017, at 8:10 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Mon Jan 16 2017, Charles Srstka  wrote:
> 
>> On Jan 16, 2017, at 6:42 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>>> 
>>> 
>>> on Mon Jan 16 2017, Charles Srstka >> > wrote:
>>> 
>> 
> On Jan 16, 2017, at 7:49 AM, Chris Eidhof via swift-evolution 
>  wrote:
> 
> Hi,
> 
> How does everyone feel about adding a second version of `reduce` to
 
> `Sequence`? Instead of a `combine` function that's of type `(A,
> Element) -> A`, it would be `(inout A, Element) -> ()`. This way, we
> can write nice functionals algorithms, but have the benefits of
> inout (mutation within the function, and hopefully some copy
> eliminations).
> 
> IIRC, Loïc Lecrenier first asked this on Twitter. I've been using it
> ever since, because it can really improve readability (the possible
> performance gain is nice, too).
> 
> Here's `reduce` with an `inout` parameter, including a sample:
> https://gist.github.com/chriseidhof/fd3e9aa621569752d1b04230f92969d7
> 
> -- 
> Chris Eidhof
 
 I did this in my own private code a while ago. There is one drawback, 
 which is that Swift’s type
 inference system isn’t quite up to handling it. For example, doing this 
 results in an “ambiguous
 reference to member” warning:
 
 range.reduce([Int]()) { $0.append($1) }
>>> 
>>> The diagnostic could be better, but the compiler shouldn't let you do
>>> that, because it requires passing an unnamed temporary value ([Int]())
>>> as inout.
>> 
>> No it doesn’t. The signature of the method is:
>> 
>> func reduce(_ initial: A, combine: (inout A, Iterator.Element) -> ()) -> A
>> 
>> The unnamed temporary value is “initial” here, which is not passed as inout; 
>> the inout parameter is
>> the first argument to the “combine” closure. The value represented by the 
>> ‘initial’ parameter is
>> passed to the closure, true, but only after being stored in a not-unnamed 
>> ‘var’ variable, as you can
>> see from the source of the proposed method:
>> 
>> func reduce(_ initial: A, combine: (inout A, Iterator.Element) -> ()) -> 
>> A {
>>var result = initial
>>for element in self {
>>combine(, element)
>>}
>>return result
>> }
>> 
>> Therefore, I don’t understand this objection.
>> 
 One would think that the type of this closure should be clear:
 
 1) The closure calls append(), a mutating function, so $0 must be inout.
 
 2) The closure doesn’t return anything, which should rule out the
 default implementations of reduce,
>>> 
>>> The closure *does* return something: (), the empty tuple
>> 
>> But it’s not what it’s supposed to return. Sequence’s implementation
>> of reduce, which the compiler thinks matches the above, is declared
>> like this:
>> 
>> public func reduce(_ initialResult: Result, _
>> nextPartialResult: (Result, Self.Iterator.Element) throws -> Result)
>> rethrows -> Result
>> 
>> The closure is supposed to return Result, which in this case would be
>> [Int]. It doesn’t, so I’m not sure why the compiler is thinking this
>> is a match.
> 
> Okay, sounds like I'm totally wrong! Has to happen at least once in a
> lifetime, doesn't it? 
> 
> So please file bug reports for these issues.

This one should already be fixed in master. If it isn't, definitely file a new 
one!

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

Re: [swift-evolution] Reduce with inout

[Dave Abrahams via swift-evolution]

on Mon Jan 16 2017, Charles Srstka  wrote:

> On Jan 16, 2017, at 6:42 PM, Dave Abrahams via swift-evolution 
>  wrote:
>> 
>> 
>> on Mon Jan 16 2017, Charles Srstka > > wrote:
>> 
>
 On Jan 16, 2017, at 7:49 AM, Chris Eidhof via swift-evolution 
  wrote:
 
 Hi,
 
 How does everyone feel about adding a second version of `reduce` to
>>> 
 `Sequence`? Instead of a `combine` function that's of type `(A,
 Element) -> A`, it would be `(inout A, Element) -> ()`. This way, we
 can write nice functionals algorithms, but have the benefits of
 inout (mutation within the function, and hopefully some copy
 eliminations).
 
 IIRC, Loïc Lecrenier first asked this on Twitter. I've been using it
 ever since, because it can really improve readability (the possible
 performance gain is nice, too).
 
 Here's `reduce` with an `inout` parameter, including a sample:
 https://gist.github.com/chriseidhof/fd3e9aa621569752d1b04230f92969d7
 
 -- 
 Chris Eidhof
>>> 
>>> I did this in my own private code a while ago. There is one drawback, which 
>>> is that Swift’s type
>>> inference system isn’t quite up to handling it. For example, doing this 
>>> results in an “ambiguous
>>> reference to member” warning:
>>> 
>>> range.reduce([Int]()) { $0.append($1) }
>> 
>> The diagnostic could be better, but the compiler shouldn't let you do
>> that, because it requires passing an unnamed temporary value ([Int]())
>> as inout.
>
> No it doesn’t. The signature of the method is:
>
> func reduce(_ initial: A, combine: (inout A, Iterator.Element) -> ()) -> A
>
> The unnamed temporary value is “initial” here, which is not passed as inout; 
> the inout parameter is
> the first argument to the “combine” closure. The value represented by the 
> ‘initial’ parameter is
> passed to the closure, true, but only after being stored in a not-unnamed 
> ‘var’ variable, as you can
> see from the source of the proposed method:
>
> func reduce(_ initial: A, combine: (inout A, Iterator.Element) -> ()) -> A 
> {
> var result = initial
> for element in self {
> combine(, element)
> }
> return result
> }
>
> Therefore, I don’t understand this objection.
>
>>> One would think that the type of this closure should be clear:
>>> 
>>> 1) The closure calls append(), a mutating function, so $0 must be inout.
>>> 
>>> 2) The closure doesn’t return anything, which should rule out the
>>> default implementations of reduce,
>> 
>> The closure *does* return something: (), the empty tuple
>
> But it’s not what it’s supposed to return. Sequence’s implementation
> of reduce, which the compiler thinks matches the above, is declared
> like this:
>
> public func reduce(_ initialResult: Result, _
> nextPartialResult: (Result, Self.Iterator.Element) throws -> Result)
> rethrows -> Result
>
> The closure is supposed to return Result, which in this case would be
> [Int]. It doesn’t, so I’m not sure why the compiler is thinking this
> is a match.

Okay, sounds like I'm totally wrong! Has to happen at least once in a
lifetime, doesn't it? 

So please file bug reports for these issues.


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

Re: [swift-evolution] Reduce with inout

[Charles Srstka via swift-evolution]

On Jan 16, 2017, at 6:42 PM, Dave Abrahams via swift-evolution 
 wrote:
> 
> 
> on Mon Jan 16 2017, Charles Srstka  > wrote:
> 
>>> On Jan 16, 2017, at 7:49 AM, Chris Eidhof via swift-evolution 
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>> How does everyone feel about adding a second version of `reduce` to
>> 
>>> `Sequence`? Instead of a `combine` function that's of type `(A,
>>> Element) -> A`, it would be `(inout A, Element) -> ()`. This way, we
>>> can write nice functionals algorithms, but have the benefits of
>>> inout (mutation within the function, and hopefully some copy
>>> eliminations).
>>> 
>>> IIRC, Loïc Lecrenier first asked this on Twitter. I've been using it
>>> ever since, because it can really improve readability (the possible
>>> performance gain is nice, too).
>>> 
>>> Here's `reduce` with an `inout` parameter, including a sample:
>>> https://gist.github.com/chriseidhof/fd3e9aa621569752d1b04230f92969d7
>>> 
>>> -- 
>>> Chris Eidhof
>> 
>> I did this in my own private code a while ago. There is one drawback, which 
>> is that Swift’s type
>> inference system isn’t quite up to handling it. For example, doing this 
>> results in an “ambiguous
>> reference to member” warning:
>> 
>> range.reduce([Int]()) { $0.append($1) }
> 
> The diagnostic could be better, but the compiler shouldn't let you do
> that, because it requires passing an unnamed temporary value ([Int]())
> as inout.

No it doesn’t. The signature of the method is:

func reduce(_ initial: A, combine: (inout A, Iterator.Element) -> ()) -> A

The unnamed temporary value is “initial” here, which is not passed as inout; 
the inout parameter is the first argument to the “combine” closure. The value 
represented by the ‘initial’ parameter is passed to the closure, true, but only 
after being stored in a not-unnamed ‘var’ variable, as you can see from the 
source of the proposed method:

func reduce(_ initial: A, combine: (inout A, Iterator.Element) -> ()) -> A {
var result = initial
for element in self {
combine(, element)
}
return result
}

Therefore, I don’t understand this objection.

>> One would think that the type of this closure should be clear:
>> 
>> 1) The closure calls append(), a mutating function, so $0 must be inout.
>> 
>> 2) The closure doesn’t return anything, which should rule out the
>> default implementations of reduce,
> 
> The closure *does* return something: (), the empty tuple

But it’s not what it’s supposed to return. Sequence’s implementation of reduce, 
which the compiler thinks matches the above, is declared like this:

public func reduce(_ initialResult: Result, _ nextPartialResult: 
(Result, Self.Iterator.Element) throws -> Result) rethrows -> Result

The closure is supposed to return Result, which in this case would be [Int]. It 
doesn’t, so I’m not sure why the compiler is thinking this is a match.

Charles

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

Re: [swift-evolution] Reduce with inout

[Charles Srstka via swift-evolution]

> On Jan 16, 2017, at 7:49 AM, Chris Eidhof via swift-evolution 
>  wrote:
> 
> Hi,
> 
> How does everyone feel about adding a second version of `reduce` to 
> `Sequence`? Instead of a `combine` function that's of type `(A, Element) -> 
> A`, it would be `(inout A, Element) -> ()`. This way, we can write nice 
> functionals algorithms, but have the benefits of inout (mutation within the 
> function, and hopefully some copy eliminations).
> 
> IIRC, Loïc Lecrenier first asked this on Twitter. I've been using it ever 
> since, because it can really improve readability (the possible performance 
> gain is nice, too).
> 
> Here's `reduce` with an `inout` parameter, including a sample: 
> https://gist.github.com/chriseidhof/fd3e9aa621569752d1b04230f92969d7
> 
> -- 
> Chris Eidhof

I did this in my own private code a while ago. There is one drawback, which is 
that Swift’s type inference system isn’t quite up to handling it. For example, 
doing this results in an “ambiguous reference to member” warning:

range.reduce([Int]()) { $0.append($1) }

One would think that the type of this closure should be clear:

1) The closure calls append(), a mutating function, so $0 must be inout.

2) The closure doesn’t return anything, which should rule out the default 
implementations of reduce, all of which should require the closure to return 
[Int].

This means that the closure has to be explicitly typed, as you did in your 
example, which is kind of cumbersome.

However, the performance benefits are simply astonishing:

import Foundation

extension Sequence {
func reduce(_ initial: A, combine: (inout A, Iterator.Element) -> 
()) -> A {
var result = initial
for element in self {
combine(, element)
}
return result
}
}

func timeIt(closure: () -> T) -> T {
let startDate = Date()
defer { print("elapsed: \(Date().timeIntervalSince(startDate))") }
return closure()
}

let range = 0..<100

let arr1: [Int] = timeIt {
var arr: [Int] = []

for i in range {
arr.append(i)
}

return arr
}

// use the array, to prevent this from all getting optimized away
print("arr1 has \(arr1.count) elements")

let arr2 = timeIt { range.reduce([]) { (arr: inout [Int], elem) in 
arr.append(elem) } }
print("yours has \(arr2.count) elements")

let arr3 = timeIt { range.reduce([]) { $0 + [$1] } }
print("default reduce has \(arr3.count) elements”)

- - - - - - -

Compiling with optimizations on and running, the output of this is:

elapsed: 0.0109230279922485
arr1 has 100 elements
elapsed: 0.00743597745895386
yours has 100 elements

You may notice the lack of output for arr3. That’s because even though I 
started running this thing ten minutes ago, it still hasn’t finished. That’s 
right; the for loop and the inout reduce can both finish this in about 0.01 
seconds, whereas the copy-based reduce() needs something greater than 10 
minutes. I don’t even know how long it actually takes to finish this test, 
because the last time I did this I eventually got sick of waiting and killed 
the process. So, I don’t know quite how many orders of magnitude slower it is, 
but it’s a lot.

Charles

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

Re: [swift-evolution] Reduce with inout

[Dave Abrahams via swift-evolution]

on Mon Jan 16 2017, Chris Eidhof  wrote:

> Hi,
>
> How does everyone feel about adding a second version of `reduce` to
> `Sequence`? Instead of a `combine` function that's of type `(A, Element) ->
> A`, it would be `(inout A, Element) -> ()`. This way, we can write nice
> functionals algorithms, but have the benefits of inout (mutation within the
> function, and hopefully some copy eliminations).
>
> IIRC, Loïc Lecrenier first asked this on Twitter. I've been using it ever
> since, because it can really improve readability (the possible performance
> gain is nice, too).
>
> Here's `reduce` with an `inout` parameter, including a sample:
> https://gist.github.com/chriseidhof/fd3e9aa621569752d1b04230f92969d7

+1

-- 
-Dave

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

[swift-evolution] Reduce with inout

[Chris Eidhof via swift-evolution]

Hi,

How does everyone feel about adding a second version of `reduce` to
`Sequence`? Instead of a `combine` function that's of type `(A, Element) ->
A`, it would be `(inout A, Element) -> ()`. This way, we can write nice
functionals algorithms, but have the benefits of inout (mutation within the
function, and hopefully some copy eliminations).

IIRC, Loïc Lecrenier first asked this on Twitter. I've been using it ever
since, because it can really improve readability (the possible performance
gain is nice, too).

Here's `reduce` with an `inout` parameter, including a sample:
https://gist.github.com/chriseidhof/fd3e9aa621569752d1b04230f92969d7

-- 
Chris Eidhof
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution