–1. I'm not sure there's a reason to draw a line from removal-of-tuple-splat to removal-of-tuple-returns, other than the idea that they both involve tuples. In a lot of languages, purely-"out" parameters are a workaround for the fact that the language wasn't designed to allow functions to return multiple values easily. Since Swift does allow this, eliminating and adding "out" params is a step *backward*, not a step forward.
"Inout" parameters at least serve an important role with respect to in-place mutability. "Out"-only parameters don't seem like something that would have much value in Swift. The syntactic distinction between inputs and outputs in Swift's function syntax is important to readability—I find the example given with "out" params to be considerably harder to parse mentally than the version that returns a tuple. From the point of view of making the language easy for newcomers to learn... replacing tuple returns with "out" parameters would be extremely harmful. On Wed, Dec 28, 2016 at 3:10 AM Anton Zhilin via swift-evolution < [email protected]> wrote: > Some people on the list wondered, why we have moved from tuples in > function parameters, but multiple returns are still implemented using > tuples? The following code still compiles: > > func position() -> (x: Int, y: Int) { > return (x: 0, y: 0) > } > let (y, x) = position() > > (Maybe it’s a bad example, because naturally we’d use Point struct. Let’s > pretend those two parameters don’t make sense as a struct.) > > What I want to discuss is if we should introduce out parameters *and* > make them the default for multiple returns for Swift 4. The syntax would > look like: > > func position(x: out Int, y: out Int) { > x = 0 > y = 0 > } > var y > position(x: let x, y: y) > > out arguments can be any patterns allowed on the left side of assignment, > including wildcard pattern and tuple destructuring pattern. > > _______________________________________________ > 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
