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 > <[email protected]> wrote: > >> On Mon, May 29, 2017 at 3:18 PM, Vladimir.S <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
