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.
-John
> On 6 Jun 2017, at 18:10, Mark Lacey via swift-evolution
> <[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
>
> _______________________________________________
> 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
