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

[Andrew Trick]

> On Feb 25, 2016, at 4:57 PM, Joe Groff via swift-evolution <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)

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160225/c6937311/attachment.html>