SE-0171: Reduce with inout


(Ben Cohen) #1

Hello Swift community,

The review of “SE-0171: Reduce with inout" begins now and runs through the Friday after next, April 14th. The proposal is available here:
  https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md <https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md>

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
  https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

  Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md <https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md>

  Reply text

  Other replies

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

Ben Cohen
Review Manager


(Ben Cohen) #2

Apologies, if you are reading this in HTML the links appear to be pointing to the incorrect proposal.

Here is the corrected link:

https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md

···

On Apr 14, 2017, at 11:37 AM, Ben Cohen <ben_cohen@apple.com> wrote:

Hello Swift community,

The review of “SE-0171: Reduce with inout" begins now and runs through the Friday after next, April 14th. The proposal is available here:
  https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
  https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

  Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md

  Reply text

  Other replies

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

Ben Cohen
Review Manager

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


(BJ Homer) #3

Does inference still work correctly when trailing closure syntax is used, if the arguments are not given types?

For example, here’s some code that works in Swift right now:

let a = [1, 2, 3, 4, 5]
let b = a.reduce([]) { (result, element) in
    return result + [element * 2]
}

Under the new proposal, this code would also be valid:

let a = [1, 2, 3, 4, 5]

let b = a.reduce([]) { (result, element) in
    result.append(element * 2)
}
Note that these both of these closures appear to have the same signature: two parameters of inferred type, and an inferred return type. The “inout” and return types differ, but neither are specified here. Will the compiler be able to correctly infer the types based on the presence or absence of a “return” statement in the closure body? If not, it seems like the first example will become ambiguous.

-BJ

···

On Apr 14, 2017, at 12:37 PM, Ben Cohen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hello Swift community,

The review of “SE-0171: Reduce with inout" begins now and runs through the Friday after next, April 14th. The proposal is available here:
  https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md <https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md>

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
  https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

  Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md <https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md>

  Reply text

  Other replies

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

Ben Cohen
Review Manager

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


(Guillaume Lessard) #4

https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md

• What is your evaluation of the proposal?

I support this proposal. It is easy to inadvertently write inefficient algorithms with reduce, and this provides a built-in solution. The parameter label is decent, and it differentiates the overloads nicely; that helps with readability. I think that the straight overload case becomes less readable; that happens to reinforce the compiler performance concern.

• Is the problem being addressed significant enough to warrant a change to Swift?

Yes. A lot of transformations can be implemented on top of ‘reduce’; this will help a class of those solutions be more efficient.

• Does this proposal fit well with the feel and direction of Swift?

Yes. A functional algorithm that embraces mutation in the name of efficiency: so swifty.

• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Participated in discussion, experimented with the concept.

Guillaume Lessard


(Matthew Johnson) #5

  • What is your evaluation of the proposal?

+0.5 because this is a half solution. I would also like to see a variant which accepts an inout argument for the reduction to accumulate into.

  • Is the problem being addressed significant enough to warrant a change to Swift?

Yes.

  • Does this proposal fit well with the feel and direction of Swift?

Yes.

  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

N/A

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick read and also followed earlier threads.


Add Various Zip-Related Types and Operations
(Ricardo Parada) #6

Hello Swift community,

The review of “SE-0171: Reduce with inout" begins now and runs through the Friday after next, April 14th. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md

  • What is your evaluation of the proposal?

+1

  • Is the problem being addressed significant enough to warrant a change to Swift?

Yes

  • Does this proposal fit well with the feel and direction of Swift?

Yes

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick read and read some of the responses.

···

On Apr 14, 2017, at 2:37 PM, Ben Cohen <ben_cohen@apple.com> wrote:


(David Hart) #7

  • What is your evaluation of the proposal?

Great addition. Reduce (aka foldl) is so useful and universal that a proposal like this that increases its usefulness is a big +1 for me.

  • Is the problem being addressed significant enough to warrant a change to Swift?

Yes.

  • Does this proposal fit well with the feel and direction of Swift?

It does fit with Swift’s direction to bring functional paradigms but also provide good performance.

  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

No.

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Followed the original discussion.


(David Rönnqvist) #8

  • What is your evaluation of the proposal?

+1 This is a small, but very useful addition. I like the argument label `into`, and using it to distinguish between the two implementations.

  • Is the problem being addressed significant enough to warrant a change to Swift?

Yes. Reducing and accumulating into structures like arrays or dictionaries can be very powerful.

  • Does this proposal fit well with the feel and direction of Swift?

Yes. It makes it easier for developers to write higher level code with good, predictable performance.

  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I don't recall other languages that provide different implementations of higher order functions with different performance characteristics. However, I've used other languages that provide different data structure implementations with different performance characteristics.

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A quick reading of the proposal and the other reviews so far.

Regards,
David


(Brad Hilton) #9

+1. Would love to see this in the standard library both for it’s improved performance and succinctness.

···

Hello Swift community,

The review of “SE-0171:Reduce with inout" begins now and runs through the Friday after next, April 14th. The proposal is available here:
https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md(https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md)

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of themessage:

Proposal link:https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md(https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md)

Reply text

Other replies

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift.When writing your review, here are some questions you might want to answer in your review:

• What is your evaluation of the proposal?
• Is the problem being addressed significant enough to warrant a change to Swift?
• Does this proposal fit well with the feel and direction of Swift?
• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available athttps://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

Ben Cohen
Review Manager


(Guillaume Lessard) #10

The mutating version would have a parameter label to differentiate it:

let a = [1, 2, 3, 4, 5]

let b = a.reduce(into: []) { (result, element) in
    result.append(element * 2)
}

···

--
GL


(Charles Srstka) #11

Yes, please. This will fill a major hole; namely, allowing us to populate collections functionally when the problem is too complex for a simple ‘map’ operation, or when the collection being built is something other than an array.

Charles

···

On Apr 14, 2017, at 1:41 PM, Ben Cohen via swift-evolution <swift-evolution@swift.org> wrote:

Apologies, if you are reading this in HTML the links appear to be pointing to the incorrect proposal.

Here is the corrected link:

https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md

On Apr 14, 2017, at 11:37 AM, Ben Cohen <ben_cohen@apple.com <mailto:ben_cohen@apple.com>> wrote:

Hello Swift community,

The review of “SE-0171: Reduce with inout" begins now and runs through the Friday after next, April 14th. The proposal is available here:
  https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
  https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

  Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md
  Reply text

  Other replies

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

Ben Cohen
Review Manager

_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org <mailto:swift-evolution-announce@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

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


(David Sweeris) #12

Out of curiosity, do you have any particular use case in mind, or do you just think that'd nicely "round out" the reduce functions (which would be fine with me).

- Dave Sweeris

···

On Apr 14, 2017, at 15:33, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

   • What is your evaluation of the proposal?

+0.5 because this is a half solution. I would also like to see a variant which accepts an inout argument for the reduction to accumulate into.


(Howard Lovatt) #13

review of “SE-0171: Reduce with inout"

  • What is your evaluation of the proposal?

Good addition. Into is good name.

  • Is the problem being addressed significant enough to warrant a change to Swift?

Yes. I have written my own version.

  • Does this proposal fit well with the feel and direction of Swift?

Yes. Improving collections worth while.

  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

The other liveries I have used with collect have had mutable versions. The Swift existing immutable version is the outlier for me.

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick read.

-- Howard.

···

On 15 Apr 2017, at 4:41 am, Ben Cohen <ben_cohen@apple.com> wrote:

Apologies, if you are reading this in HTML the links appear to be pointing to the incorrect proposal.

Here is the corrected link:

https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md

On Apr 14, 2017, at 11:37 AM, Ben Cohen <ben_cohen@apple.com> wrote:

Hello Swift community,

The review of “SE-0171: Reduce with inout" begins now and runs through the Friday after next, April 14th. The proposal is available here:
  https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
  https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

  Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md

  Reply text

  Other replies

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

Ben Cohen
Review Manager

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

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


#14

+ 1 for me . I found that the value semantics bring some problem in swift.
It is not suitable for some places.

*best wishes for you *

···

2017-04-19 4:29 GMT+08:00 Brad Hilton via swift-evolution < swift-evolution@swift.org>:

+1. Would love to see this in the standard library both for it’s improved
performance and succinctness.

> Hello Swift community,
>
> The review of “SE-0171:Reduce with inout" begins now and runs through
the Friday after next, April 14th. The proposal is available here:
> https://github.com/apple/swift-evolution/blob/master/
proposals/0171-reduce-with-inout.md(https://github.com/
apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-
representation.md)
>
> Reviews are an important part of the Swift evolution process. All
reviews should be sent to the swift-evolution mailing list at
> https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the
review manager. When replying, please try to keep the proposal link at the
top of themessage:
>
> Proposal link:https://github.com/apple/swift-evolution/blob/master/
proposals/0171-reduce-with-inout.md(https://github.com/
apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-
representation.md)
>
> Reply text
>
> Other replies
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift.When writing your review, here are some questions you might want to
answer in your review:
>
> • What is your evaluation of the proposal?
> • Is the problem being addressed significant enough to warrant a change
to Swift?
> • Does this proposal fit well with the feel and direction of Swift?
> • If you have used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?
> • How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
>
> More information about the Swift evolution process is available
athttps://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> Ben Cohen
> Review Manager
>
>
>
>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(BJ Homer) #15

Ah, that makes sense. I was forgetting that the parameter label was on the initial value.

+1 from me!

-BJ

···

On Apr 14, 2017, at 3:07 PM, Guillaume Lessard via swift-evolution <swift-evolution@swift.org> wrote:

The mutating version would have a parameter label to differentiate it:

let a = [1, 2, 3, 4, 5]

let b = a.reduce(into: []) { (result, element) in
   result.append(element * 2)
}

--
GL

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


(Matthew Johnson) #16

  • What is your evaluation of the proposal?

+0.5 because this is a half solution. I would also like to see a variant which accepts an inout argument for the reduction to accumulate into.

Out of curiosity, do you have any particular use case in mind, or do you just think that'd nicely "round out" the reduce functions (which would be fine with me).

This would be useful in any use case that involves reducing data that isn’t all available at the same time for one reason or another (batches arrive periodically, data is processed in chunks to avoid loading everything into memory, etc).

IMO the most fundamental variation of `reduce` Swift could offer is the one that takes and `inout` accumulator. The others can easily be defined in terms of that.

···

On Apr 14, 2017, at 9:05 PM, David Sweeris <davesweeris@mac.com> wrote:

On Apr 14, 2017, at 15:33, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

- Dave Sweeris


(TJ Usiyan) #17

+1 from me. I currently use reduce and just deal with the costs.

···

On Fri, Apr 14, 2017 at 10:15 PM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote:

> On Apr 14, 2017, at 9:05 PM, David Sweeris <davesweeris@mac.com> wrote:
>
>
>> On Apr 14, 2017, at 15:33, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote:
>>
>>
>>> • What is your evaluation of the proposal?
>>
>> +0.5 because this is a half solution. I would also like to see a
variant which accepts an inout argument for the reduction to accumulate
into.
>
> Out of curiosity, do you have any particular use case in mind, or do you
just think that'd nicely "round out" the reduce functions (which would be
fine with me).

This would be useful in any use case that involves reducing data that
isn’t all available at the same time for one reason or another (batches
arrive periodically, data is processed in chunks to avoid loading
everything into memory, etc).

IMO the most fundamental variation of `reduce` Swift could offer is the
one that takes and `inout` accumulator. The others can easily be defined
in terms of that.

>
> - Dave Sweeris

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


(Dave Abrahams) #18

It should work to do this:

  existingAccumulator = reduce(into: existingAccumulator) { ... }

If reduce is inlined, ARC is doing its job right, and the closure isn't
throwing, it shouldn't even cost a copy of existingAccumulator.

If you have a heaviweight accumulator with value semantics and ARC
isn't cutting it for you, you can do this ugly thing instead.

  extension Optional {
    mutating func release() -> Wrapped {
      defer { self = nil }
      return self!
    }
  }

  var accumulator: AccumulatorType? = AccumulatorType()
  accumulator = reduce(into: accumulator.release()) { ... }

but then you lose the accumulator if the closure throws. So, I guess
I'm agreeing with you that the version with the inout accumulator is
more fundamental.

But that's not the only criterion. Is it as useful and commonly
convenient? If we were to have both versions, how would you name them?

···

on Fri Apr 14 2017, Matthew Johnson <swift-evolution@swift.org> wrote:

On Apr 14, 2017, at 9:05 PM, David Sweeris <davesweeris@mac.com> wrote:

On Apr 14, 2017, at 15:33, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

  • What is your evaluation of the proposal?

+0.5 because this is a half solution. I would also like to see a
variant which accepts an inout argument for the reduction to
accumulate into.

Out of curiosity, do you have any particular use case in mind, or do
you just think that'd nicely "round out" the reduce functions (which
would be fine with me).

This would be useful in any use case that involves reducing data that
isn’t all available at the same time for one reason or another
(batches arrive periodically, data is processed in chunks to avoid
loading everything into memory, etc).

IMO the most fundamental variation of `reduce` Swift could offer is
the one that takes and `inout` accumulator. The others can easily be
defined in terms of that.

--
-Dave


Why doesn't "reduce(into:)" include a variant that takes an "inout" input?
(Matthew Johnson) #19

• What is your evaluation of the proposal?

+0.5 because this is a half solution. I would also like to see a
variant which accepts an inout argument for the reduction to
accumulate into.

Out of curiosity, do you have any particular use case in mind, or do
you just think that'd nicely "round out" the reduce functions (which
would be fine with me).

This would be useful in any use case that involves reducing data that
isn’t all available at the same time for one reason or another
(batches arrive periodically, data is processed in chunks to avoid
loading everything into memory, etc).

IMO the most fundamental variation of `reduce` Swift could offer is
the one that takes and `inout` accumulator. The others can easily be
defined in terms of that.

It should work to do this:

existingAccumulator = reduce(into: existingAccumulator) { ... }

If reduce is inlined, ARC is doing its job right, and the closure isn't
throwing, it shouldn't even cost a copy of existingAccumulator.

If you have a heaviweight accumulator with value semantics and ARC
isn't cutting it for you, you can do this ugly thing instead.

extension Optional {
   mutating func release() -> Wrapped {
     defer { self = nil }
     return self!
   }
}

var accumulator: AccumulatorType? = AccumulatorType()
accumulator = reduce(into: accumulator.release()) { ... }

but then you lose the accumulator if the closure throws. So, I guess
I'm agreeing with you that the version with the inout accumulator is
more fundamental.

Even if this would work I don’t think it’s a great option. Accepting an inout accumulator is a far more straightforward programming model with clear performance semantics that don’t require detailed implementation knowledge.

But that's not the only criterion. Is it as useful and commonly
convenient?

I would say it is commonly useful. When it is required it is as convenient as possible. When an inout accumulator is not required it is admittedly somewhat less convenient.

Whether it is *as* useful and convenient as the proposed variation probably depends on the domain. Each has their strength with the proposed version probably being a bit more frequently desired.

If we were to have both versions, how would you name them?

This is a tough question. The proposed `into:` label makes sense for both the inout accumulator and the proposed variation but I’ll assume overloading won’t be considered for the reasons stated in the proposal. `intoCopyOf:` would make sense for the proposed copying variation but would penalize it with verbosity and doesn’t copy reference types despite implying that.

The `mutating:` label described in the alternatives considered section of the proposal might might be the best option. One downside would be if the difference between `into:` and `mutating:` isn't sufficiently clear. Given that both the types *and* the labels distinct I think it’s probably ok. The second potential source of confusion would be if using `mutating:` as a label might cause some confusion with mutating methods. Again, a quick glance at the types reveals that the method is not mutating and the accumulator argument is taken as inout.

What is your thought on using the `into` for the proposed variation and `mutating` for the variation with an inout accumulator?

···

On Apr 16, 2017, at 12:47 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Fri Apr 14 2017, Matthew Johnson <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Apr 14, 2017, at 9:05 PM, David Sweeris <davesweeris@mac.com> wrote:

On Apr 14, 2017, at 15:33, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

--
-Dave

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


(Jaden Geller) #20

• What is your evaluation of the proposal?

+0.5 because this is a half solution. I would also like to see a
variant which accepts an inout argument for the reduction to
accumulate into.

Out of curiosity, do you have any particular use case in mind, or do
you just think that'd nicely "round out" the reduce functions (which
would be fine with me).

This would be useful in any use case that involves reducing data that
isn’t all available at the same time for one reason or another
(batches arrive periodically, data is processed in chunks to avoid
loading everything into memory, etc).

IMO the most fundamental variation of `reduce` Swift could offer is
the one that takes and `inout` accumulator. The others can easily be
defined in terms of that.

It should work to do this:

existingAccumulator = reduce(into: existingAccumulator) { ... }

If reduce is inlined, ARC is doing its job right, and the closure isn't
throwing, it shouldn't even cost a copy of existingAccumulator.

If you have a heaviweight accumulator with value semantics and ARC
isn't cutting it for you, you can do this ugly thing instead.

extension Optional {
   mutating func release() -> Wrapped {
     defer { self = nil }
     return self!
   }
}

var accumulator: AccumulatorType? = AccumulatorType()
accumulator = reduce(into: accumulator.release()) { ... }

but then you lose the accumulator if the closure throws. So, I guess
I'm agreeing with you that the version with the inout accumulator is
more fundamental.

Even if this would work I don’t think it’s a great option. Accepting an inout accumulator is a far more straightforward programming model with clear performance semantics that don’t require detailed implementation knowledge.

But that's not the only criterion. Is it as useful and commonly
convenient?

I would say it is commonly useful. When it is required it is as convenient as possible. When an inout accumulator is not required it is admittedly somewhat less convenient.

Whether it is *as* useful and convenient as the proposed variation probably depends on the domain. Each has their strength with the proposed version probably being a bit more frequently desired.

If we were to have both versions, how would you name them?

This is a tough question. The proposed `into:` label makes sense for both the inout accumulator and the proposed variation but I’ll assume overloading won’t be considered for the reasons stated in the proposal. `intoCopyOf:` would make sense for the proposed copying variation but would penalize it with verbosity and doesn’t copy reference types despite implying that.

It seems to me that it isn’t problematic to overload with an `inout` variant. It is always clear to the compiler which to choose based on the presence or lack of a `&` character.

The `mutating:` label described in the alternatives considered section of the proposal might might be the best option. One downside would be if the difference between `into:` and `mutating:` isn't sufficiently clear. Given that both the types *and* the labels distinct I think it’s probably ok. The second potential source of confusion would be if using `mutating:` as a label might cause some confusion with mutating methods. Again, a quick glance at the types reveals that the method is not mutating and the accumulator argument is taken as inout.

What is your thought on using the `into` for the proposed variation and `mutating` for the variation with an inout accumulator?

--
-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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

Cheers,
Jaden Geller

···

On Apr 17, 2017, at 2:37 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

On Apr 16, 2017, at 12:47 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
on Fri Apr 14 2017, Matthew Johnson <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Apr 14, 2017, at 9:05 PM, David Sweeris <davesweeris@mac.com <mailto:davesweeris@mac.com>> wrote:

On Apr 14, 2017, at 15:33, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: