-1
On Wed, Dec 28, 2016 at 9:37 AM Tony Allevato via swift-evolution <
swift-evolution@swift.org> wrote:
> –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 <
> swift-evolution@swift.org> 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
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
