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 <cocoadev-AT-charlessoft.com> 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 <swift-evolution@swift.org > >>> <mailto:swift-evolution@swift.org>> 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:
>>>>> reduce-with-inout.swift · GitHub
>>>>>
>>>>> --
>>>>> 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<A>(_ 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<A>(_ initial: A, combine: (inout A, Iterator.Element) ->
()) -> A {
>> var result = initial
>> for element in self {
>> combine(&result, 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<Result>(_ 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