> On Jun 6, 2017, at 10:33 AM, John Holdsworth <[email protected]> wrote: > > Hi Mark, > > one example of what was possible in Swift 3 but not convenient in Swift4 as > it stands is the following: > > let bookTuples = [(1, "john", "book", "novel", 9.99, []), > (2, "john", "book", "novel", 9.99, ["chapt1", > "chapt2"])] > > print(""" > <?xml version="1.0"?> > <catalog> > \(bookTuples.map { > (id, author, title, genre, price, chapters) in """ > <book id="bk\(id)" empty=""> > <author>\(author)</author> > <title>\(title)</title> > <genre>\(genre)</genre> > <price>\(price)</price> > <chapters> > \(chapters.map { > (heading) in """ > <heading>\(heading)</heading> > > """}.joined(separator:"") > ) </chapters> > </book> > > """}.joined(separator:"") > )</catalog> > """) > > It would be great if this functionality could be preserved somehow. ((double > brackets)) perhaps > but it would help library maintainers if this could also be back ported into > Swift 3.2.
Unless I am missing something this is an example of tuple destructuring. I’m looking for examples of other issues. Mark > > -John > >> On 6 Jun 2017, at 18:10, Mark Lacey via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >>> >>> On Jun 6, 2017, at 8:42 AM, Ray Fix via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> >>> FWIW, after doing a project migration last night and this morning, I am >>> reluctantly +1 for reverting SE-0110 and seeing a new proposal that can be >>> properly evaluated. The split-the-difference compromise mentioned seems >>> like just that, a compromise that will need to be revisited anyway. >>> >>> While I agreed with the spirit of the original proposal, the assertion that >>> "Minor changes to user code may be required if this proposal is accepted.” >>> seems like it underestimated the magnitude of the impact. In almost every >>> case, my code lost clarity. >> >> Did you run into issues other than the “tuple destructuring” issue that >> began this thread? >> >> If so, can you provide some examples to illustrate what other issues people >> are hitting in practice? >> >> I put “tuple destructuring” in quotes here because although it looks very >> much like what is happening in Swift 3 and earlier, there was no real tuple >> destructuring support in parameters (as evidenced by the fact that things >> like (x, (y, z)) never worked). >> >> The behavior of allowing: >> [“key” : 1].map { key, value in … } >> is the result of allowing the two-argument closure to be passed to a >> function (map) that expects a one-argument function parameter where the >> argument is a two element tuple. >> >> I don’t think anyone disagrees that removing this functionality without >> simultaneously providing a real destructuring feature regresses the >> usability of the language where closures are concerned. >> >> Understanding other fallout from SE-0110 will be helpful in guiding the >> decision of how to move forward from here. >> >> Mark >> >>> >>> Other aspects of the migration went quite smoothly. >>> >>> BTW, if I were at WWDC this year I would be in the Swift lab pestering them >>> about this. Hopefully that feedback is happening. :) >>> >>> Ray >>> >>> >>>> On Jun 6, 2017, at 8:22 AM, Shawn Erickson via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>> >>>> On Tue, Jun 6, 2017 at 7:18 AM Gwendal Roué via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>>> Le 6 juin 2017 à 15:30, Vladimir.S <[email protected] >>>>> <mailto:[email protected]>> a écrit : >>>>> >>>>> I'm just trying to understand your opinion. >>>>> Let me know, what result do you *expect* for this Swift4 code given what >>>>> SE-0066 requires for function types: >>>>> >>>>> func foo(x : (Int, Int))->() {} >>>>> >>>>> print(type(of: foo)) // ?? >>>>> print(foo is (_: Int, _: Int)->()) // ?? >>>> >>>> I couldn't care less. >>>> >>>> What I care about: the code regressions introduced by SE-0110 (look at >>>> previous messages in this long thread, and the ridiculous state of >>>> closures that eat tuples), and the migration bugs (look at Xcode 9 release >>>> notes). >>>> >>>> Note that many of Apple's swift team are likely swamped with WWDC at the >>>> moment. They are also dealing with merging out their private changes >>>> announced so far at WWDC. Xcode 9 is prerelease still so expect things to >>>> get revised to some degree before the final release. >>>> >>>> Not say to not voice concerns but at this time some patience will be >>>> needed. >>>> >>>> -Shawn >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
