Accidentally sent this offlist (why no 'reply to' header?) -thislooksfun (tlf)
> On Dec 28, 2016, at 9:52 AM, thislooksfun <[email protected]> wrote: > > This already basically exists in the form `inout` > // Define the function > func position(x: inout Int, y: inout Int) { > x = 0 > y = 0 > } > > // Create the variables you want to assign (they do have to be initialized > beforehand) > var x = 0, y = 0 > // And call it! Remember to prefix with & when using a primitive type (not > 100% sure what kinds you don't need to specify that for, but the compiler > will tell you). > position(x: &x, y: &y) > There is no way to define a variable from the value passed to an `inout` > parameter (it does need to go 'in' as well, after all), but other than that > it seems to be what you're asking for. > > -thislooksfun (tlf) > > >> On Dec 28, 2016, at 5:09 AM, Anton Zhilin via swift-evolution >> <[email protected] <mailto:[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] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
