[swift-evolution] Revisiting SE-0110

[Robert Bennett]

I think the goal of SE 0110 and to a lesser extent 0066 was to disallow this level of intelligence in the compiler. While technically feasible, it's not desirable to overload parentheses in this manner.

> On May 29, 2017, at 3:41 PM, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Mon, May 29, 2017 at 3:18 PM, Vladimir.S <svabox at gmail.com> wrote:
>>> On 29.05.2017 21:08, Nevin Brackett-Rozinsky wrote:
>>> barTuple{ (x, y) in }   // valid, destructuring one tuple
>>> barTuple{ ((x, y)) in } // valid, destructuring one tuple with optional parentheses
>> 
>> Here is the problem for me. According to SE-0066 closure declared as {(x,y) in} should be of type (Int,Int)->() and not ((Int,Int))->().
>> Why do you want to be able to pass wrong function/closure type into barTuple?
> 
>  I don’t.
> 
> I want the compile to infer from context whether “{ (x, y) in }” is of type “(_, _) -> _” with the optional parentheses included, or of type “((_, _)) -> _” with the optional parentheses elided. This is similar to how we use context to determine whether “1” is of type Int or Double or something else entirely.
> 
> If a closure appears in a context where it can only accept a tuple, such as mapping a dictionary, then obviously its type should have a tuple parameter. If a closure appears in a context where it can only accept two arguments, then obviously its type should have two parameters.
> 
> I want the compiler to figure out, when possible from context, whether the optional parentheses were included, so it “just works” for developers.
> 
> Nevin
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170529/77f83766/attachment.html>