[swift-evolution] [Pitch] Flattening the function type of unapplied instance methods

[Joe Groff]

> On Feb 25, 2016, at 10:16 PM, Andrew Trick <atrick at apple.com> wrote:
> 
> 
>> On Feb 25, 2016, at 4:57 PM, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>>> I'm concerned about that too, but I think most of these use cases are already impeded by removing tuple argument splatting, since that makes it impossible to make a generic method transformation like `alterMethod<Receiver, Args, Ret>(method: Receiver -> Args -> Ret)`. I think these use cases can be recovered on flattened methods by explicit variadic splatting, since you could then write `alterMethod<Receiver, Args, Ret>(method: (Receiver, Args...) -> Ret)` instead.
>>> 
>>> I don’t really understand that, because the use-cases I’ve seen aren’t in generic context’s
>> 
>> Do you have an example in mind of a nongeneric use of curried methods that can't be easily rewritten in terms of a flat method type?
> 
> I may be off-track, but you mentioned the binary tree example of passing methods as binary closures. Wouldn't the converse be true for wedging state into unary func using existing class methods?
> 
> func visit(numbers: [Int], predicate: (Int) -> Bool) {
>   numbers.lazy.filter(predicate).forEach({ print($0) })
> }
> 
> // For some reason not a closure...
> class FilterNumbersWithRejects {
>   var rejects = [Int]()
> 
>   func check(val: Int) -> Bool {
>     if (val < 100) { return true }
>     rejects.append(val)
>     return false
>   }
> }
> 
> let filterNumbers = FilterNumbersWithRejects()
> visit([3, 33, 333], predicate: filterNumbers.check)
> print(filterNumbers.rejects)

I'm not proposing that we take the ability to use `filterNumbers.check` away. I'm proposing changing the type of the fully unapplied reference FilterNumbersWithRejects.check.

-Joe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160226/2d59c794/attachment.html>