[swift-evolution] Revisiting SE-0110

[Mark Lacey]

> On Jun 6, 2017, at 10:33 AM, John Holdsworth <mac at johnholdsworth.com> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> 
>>> On Jun 6, 2017, at 8:42 AM, Ray Fix via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> 
>>>> On Tue, Jun 6, 2017 at 7:18 AM Gwendal Roué via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>>> Le 6 juin 2017 à 15:30, Vladimir.S <svabox at gmail.com <mailto:svabox at gmail.com>> 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
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170606/fdc2bd93/attachment.html>