Re: [swift-evolution] Revisiting SE-0110

[Djura Retired Hunter via swift-evolution]

The “inout” modifier is probably one of the main culprits here. While it is 
certainly very convenient to use (and I personally use it a lot), its very 
existence seems to have some downsides that restrict Swift design decisions.

Maybe there is a solution though: make “inout” distribute over elements of a 
tuple, something that actually already happens. The following code compiles and 
works in Xcode 9 beta:

———

protocol Incrementable {
mutating func addOne()
}

func incrementFirstAndPrintSecond1(tuple: inout (A, B)) {
tuple.0.addOne()
print(tuple.1)
}

extension Int: Incrementable {
mutating func addOne() {
self += 1
}
}

var m1 = (42,"this will be printed")
incrementFirstAndPrintSecond1(tuple: ) /// prints "this will be printed"
print(m1.0) /// prints "43"

func incrementFirstAndPrintSecond2(first: inout A, second: 
inout B) {
first.addOne()
print(second)
}

var m21 = 42
var m22 = "this will be printed"
incrementFirstAndPrintSecond2(first: , second: ) /// prints "this will 
be printed"
print(m21) /// prints "43"

func applying1(value: A, f: (inout A) -> ()) -> A {
var m = value
f()
return m
}

let x1 = applying1(value: 42) { (a: inout Int) in
a.addOne()
}
print(x1) /// prints "43"

func applying2(value: (A,B), f: (inout (A,B)) -> ()) -> (A,B) {
var m = value
f()
return m
}

let x2 = applying2(value: (42,"OK")) { (tuple: inout (Int,String)) in
tuple.0.addOne()
}
print(x2) /// prints "(43, OK)"

func applying3(first: A, second: B, f: (inout A, inout B) -> ()) -> (A,B) {
var m1 = first
var m2 = second
f(,)
return (m1,m2)
}

let x3 = applying3(first: 42, second: "OK") { (a: inout Int, b: inout String) in
a.addOne()
}
print(x3) /// prints "(43, OK)"

———

As you can see, a function with a single inout tuple corresponds to a function 
with two inout arguments. This means that in a hypothetic model with isomorphic 
tuples and arguments, a tuple could be used in place of a subset of the 
arguments only if:

- none of the arguments in the subset is inout;
- all the arguments in the subset are inout, thus the tuple is to be considered 
wholly inout;

Obviously the subset could include all arguments. This way we could take 100% 
advantage of tuple isomorphism for functions with no inout arguments (thus, 
most of them), and still gain something where inout is there.

———

 About your second point, I’m definitely not an expert in type checkers, but if 
every composition of tuples was always reduced to simplest flattened form, 
maybe the type checker could have an even easier time. What I mean is that, 
because something like ((A,B),(C,(D,E))) could be considered equivalent to 
(A,B,C,D,E), the compiler could reduce the first tuple to the second, and then 
check the latter against a potential consumer. It seems to me that 
structuring-destructuring exists as a problem only when we need to 
differentiate isomorphic tuples just by their structure: without this need, the 
problems goes away. 

Still, I don't have a deep enough understanding of how the compiler works to 
analyze this second problem in full. And as I said in my first post, if the 
distinctions are truly important at the compiler level, and there are 
impossible challenges to overcome in finite space and time to acquire a feature 
like tuple isomorphism, then there's not much to do about it. My suggestion is 
simply that, if we need to define some workarounds, we should take into account 
the fact that at the usage point tuples with same content are equivalent, and a 
potential new model for the SE-110 aftermath should at least consider this idea.

Thanks


Elviro


> Il giorno 25 giu 2017, alle ore 06:28, David Hart  ha 
> scritto:
> 
> I think the Core Team initially (pre-Swift 1) wanted to make tuples and 
> arguments isomorphic. But that model has many downsides which forced us to 
> backtrack from that model:
> 
> • Modifiers on arguments (like inout) would force us to introduce them as 
> part of the type-system on tuples, which makes for a messy model,
> • Tuple structuring and de-structuring greatly complicates the work of the 
> type-checker.
> 
> The decision was made early in the Swift-evolution timeframe to strip what 
> was left of the old model. It's much too late to backtrack now. Even if one 
> wanted to, you'd have to address the original concerns that drove us to the 
> current model.
> 
> David.
> 
> On 24 Jun 2017, at 21:12, Djura Retired Hunter via swift-evolution 
> > wrote:
> 
> 
> 
>> On Jun 23, 2017, at 7:46 AM, Elviro Rocca via swift-evolution 
>> > wrote:
>> 
>> It's probably late to just casually add a couple of cents to a 
>> discussion that has been going for so long, but it seems to me that from 
>> a user standpoint, that uses types to structure their 

Re: [swift-evolution] Revisiting SE-0110

[David Hart via swift-evolution]

I think the Core Team initially (pre-Swift 1) wanted to make tuples and 
arguments isomorphic. But that model has many downsides which forced us to 
backtrack from that model:

• Modifiers on arguments (like inout) would force us to introduce them as part 
of the type-system on tuples, which makes for a messy model,
• Tuple structuring and de-structuring greatly complicates the work of the 
type-checker.

The decision was made early in the Swift-evolution timeframe to strip what was 
left of the old model. It's much too late to backtrack now. Even if one wanted 
to, you'd have to address the original concerns that drove us to the current 
model.

David.

> On 24 Jun 2017, at 21:12, Djura Retired Hunter via swift-evolution 
>  wrote:
> 
 
 
> On Jun 23, 2017, at 7:46 AM, Elviro Rocca via swift-evolution 
>  wrote:
> 
> It's probably late to just casually add a couple of cents to a discussion 
> that has been going for so long, but it seems to me that from a user 
> standpoint, that uses types to structure their programs and define logic 
> and relationships, isomorphic types should be considered the same by the 
> compiler. The added burden of distinguishing between, to say, a function 
> that takes 2 arguments and one that takes a single tuple of two arguments 
> doesn't seem useful at all, at least from the standpoint of the types 
> involves. All the rest, like named parameters or tuple labels, are just 
> really about style and convenience, but isomorphic types, while not 
> strictly equal (the very concept of "equal" is in fact a huge deal in 
> abstract mathematics) are for all means "equivalent" for the 
> world-modeler.
 
 Doesn’t seem useful?…
 
 let myFunc: (MyTypeAlias) -> Int = /* … */
 
 Does the function pointer have a single parameter? Or does it trigger 
 Super-Secret Tuple-Destructing mode and actually indicate two parameters? 
 My secret unknown single type should always be a single type, no matter 
 what kind of type it is.
>> 
>> (A, B, C)  ((A, B), C)  (A, (B, C))
>> 
>> You’re saying partitions aren’t important. I’m saying that they are. Even 
>> though the second two tuples above are implemented like the first, I 
>> wouldn’t want them to be indistinguishable from an user’s standpoint. I 
>> wouldn’t want my two-argument functions magically become a three-argument 
>> one due to implementation details.
> 
> Why are partitions, just partitions, of tuples important? And why should 
> anybody even consider writing a function that takes a tuple as "single 
> argument" instead of just taking two arguments?
> 
> The difference between the following two functions is completely meaningless 
> from a user standpoint:
> 
> func x (tuple: (first: A, second: B))
> func y (first: A, second: B)
> 
>> 
>> My previous example will stay an one-argument function for any non-tuple 
>> type behind the alias. But if it’s a tuple type, my assumption breaks 
>> because your rules would ban tuples from being first-class types.
>> 
> 
> 
> What? Why my rules say that tuples are not first class types? I'm just saying 
> that equivalent tuples should be allowed as arguments for functions that take 
> equivalent tuples as arguments.
> 
> You examples shows a function that takes a "MyTypeAlias" as input:
> 
> - if MyTypeAlias is an alias for, say, a "Person", that function can be 
> called with an instance of "Person"
> - if MyTypeAlias is an alias for (Int,Int), that function can be called with 
> a couple of Int
> 
> What's the matter?
> 
> 
> Elviro
> 
> ___
> 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

Re: [swift-evolution] Revisiting SE-0110

[Djura Retired Hunter via swift-evolution]

>>> 
>>> 
 On Jun 23, 2017, at 7:46 AM, Elviro Rocca via swift-evolution 
 > wrote:
 
 It's probably late to just casually add a couple of cents to a discussion 
 that has been going for so long, but it seems to me that from a user 
 standpoint, that uses types to structure their programs and define logic 
 and relationships, isomorphic types should be considered the same by the 
 compiler. The added burden of distinguishing between, to say, a function 
 that takes 2 arguments and one that takes a single tuple of two arguments 
 doesn't seem useful at all, at least from the standpoint of the types 
 involves. All the rest, like named parameters or tuple labels, are just 
 really about style and convenience, but isomorphic types, while not 
 strictly equal (the very concept of "equal" is in fact a huge deal in 
 abstract mathematics) are for all means "equivalent" for the world-modeler.
>>> 
>>> Doesn’t seem useful?…
>>> 
>>> let myFunc: (MyTypeAlias) -> Int = /* … */
>>> 
>>> Does the function pointer have a single parameter? Or does it trigger 
>>> Super-Secret Tuple-Destructing mode and actually indicate two parameters? 
>>> My secret unknown single type should always be a single type, no matter 
>>> what kind of type it is.
> 
> (A, B, C)  ((A, B), C)  (A, (B, C))
> 
> You’re saying partitions aren’t important. I’m saying that they are. Even 
> though the second two tuples above are implemented like the first, I wouldn’t 
> want them to be indistinguishable from an user’s standpoint. I wouldn’t want 
> my two-argument functions magically become a three-argument one due to 
> implementation details.

Why are partitions, just partitions, of tuples important? And why should 
anybody even consider writing a function that takes a tuple as "single 
argument" instead of just taking two arguments?

The difference between the following two functions is completely meaningless 
from a user standpoint:

func x (tuple: (first: A, second: B))
func y (first: A, second: B)

> 
> My previous example will stay an one-argument function for any non-tuple type 
> behind the alias. But if it’s a tuple type, my assumption breaks because your 
> rules would ban tuples from being first-class types.
> 


What? Why my rules say that tuples are not first class types? I'm just saying 
that equivalent tuples should be allowed as arguments for functions that take 
equivalent tuples as arguments.

You examples shows a function that takes a "MyTypeAlias" as input:

- if MyTypeAlias is an alias for, say, a "Person", that function can be called 
with an instance of "Person"
- if MyTypeAlias is an alias for (Int,Int), that function can be called with a 
couple of Int

What's the matter?


Elviro

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Daryle Walker via swift-evolution]

> On Jun 24, 2017, at 12:25 PM, Djura Retired Hunter 
>  wrote:
> 
> I didn't understand your example at all. Care to elaborate?
> 
> Elviro
> 
>> Il giorno 24 giu 2017, alle ore 18:05, Daryle Walker > > ha scritto:
>> 
>> 
>>> On Jun 23, 2017, at 7:46 AM, Elviro Rocca via swift-evolution 
>>> > wrote:
>>> 
>>> It's probably late to just casually add a couple of cents to a discussion 
>>> that has been going for so long, but it seems to me that from a user 
>>> standpoint, that uses types to structure their programs and define logic 
>>> and relationships, isomorphic types should be considered the same by the 
>>> compiler. The added burden of distinguishing between, to say, a function 
>>> that takes 2 arguments and one that takes a single tuple of two arguments 
>>> doesn't seem useful at all, at least from the standpoint of the types 
>>> involves. All the rest, like named parameters or tuple labels, are just 
>>> really about style and convenience, but isomorphic types, while not 
>>> strictly equal (the very concept of "equal" is in fact a huge deal in 
>>> abstract mathematics) are for all means "equivalent" for the world-modeler.
>> 
>> Doesn’t seem useful?…
>> 
>> let myFunc: (MyTypeAlias) -> Int = /* … */
>> 
>> Does the function pointer have a single parameter? Or does it trigger 
>> Super-Secret Tuple-Destructing mode and actually indicate two parameters? My 
>> secret unknown single type should always be a single type, no matter what 
>> kind of type it is.

(A, B, C)  ((A, B), C)  (A, (B, C))

You’re saying partitions aren’t important. I’m saying that they are. Even 
though the second two tuples above are implemented like the first, I wouldn’t 
want them to be indistinguishable from an user’s standpoint. I wouldn’t want my 
two-argument functions magically become a three-argument one due to 
implementation details.

My previous example will stay an one-argument function for any non-tuple type 
behind the alias. But if it’s a tuple type, my assumption breaks because your 
rules would ban tuples from being first-class types.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Djura Retired Hunter via swift-evolution]

I didn't understand your example at all. Care to elaborate?

Elviro

> Il giorno 24 giu 2017, alle ore 18:05, Daryle Walker  ha 
> scritto:
> 
> 
>> On Jun 23, 2017, at 7:46 AM, Elviro Rocca via swift-evolution 
>> > wrote:
>> 
>> It's probably late to just casually add a couple of cents to a discussion 
>> that has been going for so long, but it seems to me that from a user 
>> standpoint, that uses types to structure their programs and define logic and 
>> relationships, isomorphic types should be considered the same by the 
>> compiler. The added burden of distinguishing between, to say, a function 
>> that takes 2 arguments and one that takes a single tuple of two arguments 
>> doesn't seem useful at all, at least from the standpoint of the types 
>> involves. All the rest, like named parameters or tuple labels, are just 
>> really about style and convenience, but isomorphic types, while not strictly 
>> equal (the very concept of "equal" is in fact a huge deal in abstract 
>> mathematics) are for all means "equivalent" for the world-modeler.
> 
> Doesn’t seem useful?…
> 
> let myFunc: (MyTypeAlias) -> Int = /* … */
> 
> Does the function pointer have a single parameter? Or does it trigger 
> Super-Secret Tuple-Destructing mode and actually indicate two parameters? My 
> secret unknown single type should always be a single type, no matter what 
> kind of type it is.
> 
> — 
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT com 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Daryle Walker via swift-evolution]

> On Jun 23, 2017, at 7:46 AM, Elviro Rocca via swift-evolution 
>  wrote:
> 
> It's probably late to just casually add a couple of cents to a discussion 
> that has been going for so long, but it seems to me that from a user 
> standpoint, that uses types to structure their programs and define logic and 
> relationships, isomorphic types should be considered the same by the 
> compiler. The added burden of distinguishing between, to say, a function that 
> takes 2 arguments and one that takes a single tuple of two arguments doesn't 
> seem useful at all, at least from the standpoint of the types involves. All 
> the rest, like named parameters or tuple labels, are just really about style 
> and convenience, but isomorphic types, while not strictly equal (the very 
> concept of "equal" is in fact a huge deal in abstract mathematics) are for 
> all means "equivalent" for the world-modeler.

Doesn’t seem useful?…

let myFunc: (MyTypeAlias) -> Int = /* … */

Does the function pointer have a single parameter? Or does it trigger 
Super-Secret Tuple-Destructing mode and actually indicate two parameters? My 
secret unknown single type should always be a single type, no matter what kind 
of type it is.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Elviro Rocca via swift-evolution]

Hi, thanks for the answer.

>> …by showing code that’s marginally different from each other, like one more 
>> nesting of parentheses, or one less label for a parameter. It seems to me 
>> that distinctions like these are just important at the compiler level, but 
>> not particularly useful from an usability standpoint.
> 
> It is your opinion that these distinctions are not “useful from a usability 
> standpoint”. My opinion, for example, differs in that I think these 
> distinctions in the structure of the types is very important, even if the 
> types “information content” is the same. Structure also conveys information 
> (and intent).
> 

What I meant by "marginally different" is a distinction like ((A,B)) != (A,B) 
which seems to me completely meaningless from a user perspective.

I'm not sure how completely isomorphic structures (represented by tuples) could 
convey different information and intent. For example:

let x: (coordinates: (Double,Double), altitude: Double) == ((A,B),C)
let y: (latitude: Double, longitude: Double, altitude: Double) ==  (A,B,C)

In this case what conveys information are the arguments labels, not the 
structure by itself. And if I really need to be specific about the information 
that I want to represent, I should probably create a new actual type, for 
example a "Position" struct, such that the example becomes:

let z: Position == (A)

That's different. What I'm referring to are just tuples in general. A function 
that expects a "Position" should get a "Position", but if a function just 
expects 3 "Double" I don't see a reason why we shouldn't be able to call it 
with both "x" and "y": of course I could do something nonsensical in this 
context, like return a sum of the 3, but here the problem is "not using types 
that are specific enough", or simply "calling the wrong function" (like 
"square" instead of "squareRoot").

>> The point is that, the following type couples are completely isomorphic to 
>> each other (meaning that they are, for all means, equivalent) and a smart 
>> type system could in theory consider them as the same thing:
>> 
>> (A) == ((A))
>> (A) == (((A)))
>> (A) == (A,())
>> (A) == ((),A,())
>> (A,B) == ((A,B))
>> (A,B) == (((A,B)))
>> (A,B) == (A,B,())
>> (A,B) == ((),A,B,())
>> (A,B) == ((),(A,B),())
> 
> To my mind, the examples should not compare equal (in fact, they shouldn’t 
> even be comparable by default because for those distinct types involved that 
> seems like a non-sensical question to me).
> 
> I might agree that a type system *could* consider these the same, but I don’t 
> think it should. For example, in the context of generic programming, the 
> structure of types (especially in degenerate cases such as e.g. empty tuples) 
> should strictly match what is expected; calling a function that expects two 
> tuples is not the same as calling that function with one tuple and so on. The 
> same goes for nesting tuples.

Could you please elaborate on this, providing some arguments for the statement 
"in the context of generic programming, the structure of types should strictly 
match what is expected"?

Thanks


Elviro
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Daniel Vollmer via swift-evolution]

Hi Elviro,

> On 23. Jun 2017, at 13:46, Elviro Rocca via swift-evolution 
>  wrote:

[snip]

> …by showing code that’s marginally different from each other, like one more 
> nesting of parentheses, or one less label for a parameter. It seems to me 
> that distinctions like these are just important at the compiler level, but 
> not particularly useful from an usability standpoint.

It is your opinion that these distinctions are not “useful from a usability 
standpoint”. My opinion, for example, differs in that I think these 
distinctions in the structure of the types is very important, even if the types 
“information content” is the same. Structure also conveys information (and 
intent).

> The point is that, the following type couples are completely isomorphic to 
> each other (meaning that they are, for all means, equivalent) and a smart 
> type system could in theory consider them as the same thing:
> 
> (A) == ((A))
> (A) == (((A)))
> (A) == (A,())
> (A) == ((),A,())
> (A,B) == ((A,B))
> (A,B) == (((A,B)))
> (A,B) == (A,B,())
> (A,B) == ((),A,B,())
> (A,B) == ((),(A,B),())

To my mind, the examples should not compare equal (in fact, they shouldn’t even 
be comparable by default because for those distinct types involved that seems 
like a non-sensical question to me).

I might agree that a type system *could* consider these the same, but I don’t 
think it should. For example, in the context of generic programming, the 
structure of types (especially in degenerate cases such as e.g. empty tuples) 
should strictly match what is expected; calling a function that expects two 
tuples is not the same as calling that function with one tuple and so on. The 
same goes for nesting tuples.

That said, I do think there should be (better?) support for converting between 
representations, such as easily forming a tuple from a (variadic) argument 
list, and conversely splatting a tuple to arguments (not sure whether that’s 
the correct term—I’m talking about something like C++17’s std::apply).

> Again, I don't really expect these words to have any impact, considering the 
> huge discussion that has been going, and I don't certainly intend to 
> undermine any other contribution with my extremely generic statements. But I 
> felt like writing this, and I did.

Same here. :)


Respectfully,
Daniel.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Elviro Rocca via swift-evolution]

This has been a very hard discussion to follow, even for a programmer that 
mostly just silently reads these threads to get a general understanding of 
what's going on in the community.

There's an overwhelming amount of messages that point out potential bugs and 
unexpected behavior by showing code that's marginally different from each 
other, like one more nesting of parentheses, or one less label for a parameter. 
It seems to me that distinctions like these are just important at the compiler 
level, but not particularly useful from an usability standpoint. I might be 
wrong but there's a lot of discussion about convenience gained or lost by 
switching different styles of syntax that are in fact completely isomorphic to 
each other.

I also read some comments about the fact that some functional programmers 
didn't take well SE-110, and as a fellow FP I can say that the reason in not 
really about style or convenience.

The point is that, the following type couples are completely isomorphic to each 
other (meaning that they are, for all means, equivalent) and a smart type 
system could in theory consider them as the same thing:

(A) == ((A))
(A) == (((A)))
(A) == (A,())
(A) == ((),A,())
(A,B) == ((A,B))
(A,B) == (((A,B)))
(A,B) == (A,B,())
(A,B) == ((),A,B,())
(A,B) == ((),(A,B),())

It's probably late to just casually add a couple of cents to a discussion that 
has been going for so long, but it seems to me that from a user standpoint, 
that uses types to structure their programs and define logic and relationships, 
isomorphic types should be considered the same by the compiler. The added 
burden of distinguishing between, to say, a function that takes 2 arguments and 
one that takes a single tuple of two arguments doesn't seem useful at all, at 
least from the standpoint of the types involves. All the rest, like named 
parameters or tuple labels, are just really about style and convenience, but 
isomorphic types, while not strictly equal (the very concept of "equal" is in 
fact a huge deal in abstract mathematics) are for all means "equivalent" for 
the world-modeler.

Again, I don't really expect these words to have any impact, considering the 
huge discussion that has been going, and I don't certainly intend to undermine 
any other contribution with my extremely generic statements. But I felt like 
writing this, and I did.

Thanks


Elviro
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Chris Lattner via swift-evolution]

On Jun 17, 2017, at 9:18 AM, Xiaodi Wu  wrote:
> Fine by me as well, but to be clear this will be a non-trivial source 
> breaking change.

I understand your desire for caution here, and I completely agree that we don’t 
want to accidentally break code.  As established up-thread, given the planned 
changes for SE-0155, enum pattern matching isn’t affected.

The only case I’m interested in “removing” is the label part of the productions 
for the tuple patterns.  I’m not suggesting we remove shuffling (sorry for 
mentioning that, it seemed to confuse the conversation), and agree that we 
can’t regress the enum case matching behavior, even if SE-0155 is not 
implemented.

Let me be super concrete about what I’m saying.  I propose:

1. In Swift 4 mode, start *warning* about tuple labels being deprecated (given 
that SE-0155 isn’t implemented, we’d filter out cases where they exist as an 
immediate child to an enum pattern).

2. Ship that warning in some "hopefully-soon” toolchain release and Xcode beta.

3. Look for feedback on unexpected cases where this triggers.

4. If the feedback is non-existent or the cases deemed “weird”, we could 
consider enabling the warning in Swift 3.2 mode as well.

In a subsequent release, we would consider upgrading the warning to an error to 
reject the code in a subsequent swift version, but I am not suggesting that we 
do that for Swift 4.

-Chris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Chris Lattner via swift-evolution]

> On Jun 15, 2017, at 4:55 PM, Xiaodi Wu  wrote:
> 
>>> 
>>> Agreed, it may be too late to correct this (certainly we can't outright 
>>> remove it in Swift 4 if someone is using it for something important).  
>>> However if it turns out that it really isn't used, then warning about it in 
>>> 4 and removing it shortly after may be possible.
>> 
>> And I think its difficult to make the parallel between the two. SE-0110 
>> basically impacted everybody calling higher-order functions on Dictionary (+ 
>> more users from libraries like RxSwift), which makes an enormous proportion 
>> of the Swift community. On the other hand, despite the enormous amount of 
>> time I have sinked into learning, discussing and enjoying Swift, I never 
>> come upon the tuple element name syntax in patterns until Robert pointed to 
>> it out on twitter several weeks ago.
> 
> By the way, I’m not attempting to deduce that nobody uses this feature by the 
> fact I didn’t know about it. But I think it’s one interesting datapoint when 
> comparing it to SE-0110.
> 
> 
> SE-0110, **in retrospect**, has had impacts on a lot of users; prospectively, 
> it was thought to be a minor change, even after review and acceptance.
> 
> Keep in mind that this proposed change would also eliminate inline tuple 
> shuffle. For instance, the following code will cease to compile:
> 
> let x = (a: 1.0, r: 0.5, g: 0.5, b: 0.5)
> func f(color: (r: Double, g: Double, b: Double, a: Double)) {
>   print(color)
> }
> f(color: x)
> 
> It is an open question how frequently this is used. But like implicit tuple 
> destructuring, it currently Just Works(TM) and users may not realize they’re 
> making use of the feature until it’s gone.
> 

To (re)clarify, I was just talking about removing tuple element names from the 
tuple pattern grammar.  This example doesn’t use tuple patterns, so it wouldn’t 
be affected.  I’m not proposing removing tuple shuffles.

-Chris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Adrian Zubarev via swift-evolution]

I can only agree here, the language suffers from shortcuts like that. Same goes 
for access modifier on extensions, or `indirect` before enums and as already 
mentioned before me labeled tuple destructuring.

-- 
Adrian Zubarev
Sent with Airmail

Am 17. Juni 2017 um 18:09:50, Matthew Johnson via swift-evolution 
(swift-evolution@swift.org) schrieb:

#2 is debatable. It would solve an enum-based parallel to Chris’s original:

case let .foo(a: Int, b: String)  // disallowed
case .foo(a: let Int, b: let String)  // allowed, and Int/String no longer look 
like types


Doing this with #2 is what I suggested earlier.  I like this because I find the 
disallowed style to have too much cognitive load anyway.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jun 17, 2017, at 10:20 AM, Paul Cantrell via swift-evolution 
>  wrote:
> 
> Yes, agreed, the fix for Chris’s brain-bender shouldn’t revisit any of 
> SE-0155’s matching & labeling rules.
> 
> How about:
> 
> 1. Disallow labels for bare tuples in patterns. (By “bare tuples” I mean “not 
> representing associated values on an enum.”)
> 
>   let (a: x, b: y) = foo  // disallowed
>   let (x, y) = foo  // OK
> 
> 2. Maybe require “let” before individual identifiers when pattern matching on 
> associated values, while preserving SE-0155’s rules for when labels may 
> appear:
> 
>   case let .foo(a: x, b: y)  // disallowed
>   case .foo(a: let x, b: let y)  // OK
> 
> #2 is debatable. It would solve an enum-based parallel to Chris’s original:
> 
>   case let .foo(a: Int, b: String)  // disallowed
>   case .foo(a: let Int, b: let String)  // allowed, and Int/String no 
> longer look like types
> 

Doing this with #2 is what I suggested earlier.  I like this because I find the 
disallowed style to have too much cognitive load anyway.

> P
> 
>> On Jun 16, 2017, at 10:55 PM, Xiaodi Wu  wrote:
>> 
>> See:
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/035972.html
>> 
>> 
>>> On Fri, Jun 16, 2017 at 22:32 Paul Cantrell  wrote:
>>> Under these not-yet-implemented plans, if associated value labels are no 
>>> longer tuple labels, then how will pattern matching work? And what existing 
>>> pattern matching code will break / continue to work?
>>> 
>>> P
>>> 
 On Jun 16, 2017, at 10:22 PM, Xiaodi Wu  wrote:
 
 Keep in mind that once the latest proposal about enum cases is 
 implemented, these will be at least notionally no longer tuple labels but 
 rather a sugared way of spelling part of the case name. The rules 
 surrounding labels during case matching have only just been revised and 
 approved and have not even yet been implemented. I don’t think it would be 
 wise to fiddle with them again.
 
 
 On Fri, Jun 16, 2017 at 21:21 Paul Cantrell  wrote:
>>> On Jun 16, 2017, at 5:23 PM, Mark Lacey  wrote:
>>> 
>>> 
 On Jun 16, 2017, at 2:09 PM, Paul Cantrell  wrote:
 
 
> On Jun 16, 2017, at 3:43 PM, Mark Lacey  wrote:
> 
> 
>> On Jun 16, 2017, at 1:21 PM, Mark Lacey  wrote:
>> 
>> 
>>> On Jun 16, 2017, at 11:13 AM, Paul Cantrell via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> On Jun 15, 2017, at 7:17 PM, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On Thu, Jun 15, 2017 at 19:03 Víctor Pimentel 
  wrote:
> On 16 Jun 2017, at 01:55, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Thu, Jun 15, 2017 at 17:43 David Hart  
>> wrote:
>> 
>> By the way, I’m not attempting to deduce that nobody uses this 
>> feature by the fact I didn’t know about it. But I think it’s one 
>> interesting datapoint when comparing it to SE-0110.
> 
> 
> SE-0110, **in retrospect**, has had impacts on a lot of users; 
> prospectively, it was thought to be a minor change, even after 
> review and acceptance.
> 
> Keep in mind that this proposed change would also eliminate 
> inline tuple shuffle. For instance, the following code will cease 
> to compile:
> 
> let x = (a: 1.0, r: 0.5, g: 0.5, b: 0.5)
> func f(color: (r: Double, g: Double, b: Double, a: Double)) {
>   print(color)
> }
> f(color: x)
> 
> It is an open question how frequently this is used. But like 
> implicit tuple destructuring, it currently Just Works(TM) and 
> users may not realize they’re making use of the feature until 
> it’s gone.
 
 It's much much less used, by looking at open source projects I 
 doubt that a significant portion of projects would have to change 
 code because of this.
>>> 
>>> The reason that I’m urging caution is because, if I recall 
>>> correctly, that is also what we said about SE-0110 on this list. 
>>> Then, as now, we were discussing an issue with something left over 
>>> from the Swift 1 model of tuples. Then, as now, we believed that 
>>> the feature in question was rarely used. Then, as now, we believed 

Re: [swift-evolution] Revisiting SE-0110

[Xiaodi Wu via swift-evolution]

Fine by me as well, but to be clear this will be a non-trivial source
breaking change.


On Sat, Jun 17, 2017 at 11:09 Matthew Johnson 
wrote:

>
>
> Sent from my iPad
>
> On Jun 17, 2017, at 10:20 AM, Paul Cantrell via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Yes, agreed, the fix for Chris’s brain-bender shouldn’t revisit any of
> SE-0155’s matching & labeling rules.
>
> How about:
>
> 1. Disallow labels for bare tuples in patterns. (By “bare tuples” I mean
> “not representing associated values on an enum.”)
>
> let (a: x, b: y) = foo  // disallowed
> let (x, y) = foo  // OK
>
> 2. Maybe require “let” before individual identifiers when pattern matching
> on associated values, while preserving SE-0155’s rules for when labels may
> appear:
>
> case let .foo(a: x, b: y)  // disallowed
> case .foo(a: let x, b: let y)  // OK
>
> #2 is debatable. It would solve an enum-based parallel to Chris’s original:
>
> case let .foo(a: Int, b: String)  // disallowed
> case .foo(a: let Int, b: let String)  // allowed, and Int/String no longer
> look like types
>
>
> Doing this with #2 is what I suggested earlier.  I like this because I
> find the disallowed style to have too much cognitive load anyway.
>
> P
>
> On Jun 16, 2017, at 10:55 PM, Xiaodi Wu  wrote:
>
> See:
>
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/035972.html
>
>
> On Fri, Jun 16, 2017 at 22:32 Paul Cantrell  wrote:
>
>> Under these not-yet-implemented plans, if associated value labels are no
>> longer tuple labels, then how will pattern matching work? And what existing
>> pattern matching code will break / continue to work?
>>
>> P
>>
>> On Jun 16, 2017, at 10:22 PM, Xiaodi Wu  wrote:
>>
>> Keep in mind that once the latest proposal about enum cases is
>> implemented, these will be at least notionally no longer tuple labels but
>> rather a sugared way of spelling part of the case name. The rules
>> surrounding labels during case matching have only just been revised and
>> approved and have not even yet been implemented. I don’t think it would be
>> wise to fiddle with them again.
>>
>>
>> On Fri, Jun 16, 2017 at 21:21 Paul Cantrell  wrote:
>>
>>> On Jun 16, 2017, at 5:23 PM, Mark Lacey  wrote:
>>>
>>>
>>> On Jun 16, 2017, at 2:09 PM, Paul Cantrell  wrote:
>>>
>>>
>>> On Jun 16, 2017, at 3:43 PM, Mark Lacey  wrote:
>>>
>>>
>>> On Jun 16, 2017, at 1:21 PM, Mark Lacey  wrote:
>>>
>>>
>>> On Jun 16, 2017, at 11:13 AM, Paul Cantrell via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>>
>>> On Jun 15, 2017, at 7:17 PM, Xiaodi Wu via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>>
>>> On Thu, Jun 15, 2017 at 19:03 Víctor Pimentel 
>>> wrote:
>>>
 On 16 Jun 2017, at 01:55, Xiaodi Wu via swift-evolution <
 swift-evolution@swift.org> wrote:

 On Thu, Jun 15, 2017 at 17:43 David Hart  wrote:

>
> By the way, I’m not attempting to deduce that nobody uses this feature
> by the fact I didn’t know about it. But I think it’s one interesting
> datapoint when comparing it to SE-0110.
>


 SE-0110, **in retrospect**, has had impacts on a lot of users;
 prospectively, it was thought to be a minor change, even after review and
 acceptance.

 Keep in mind that this proposed change would also eliminate inline
 tuple shuffle. For instance, the following code will cease to compile:

 let x = (a: 1.0, r: 0.5, g: 0.5, b: 0.5)
 func f(color: (r: Double, g: Double, b: Double, a: Double)) {
   print(color)
 }
 f(color: x)

 It is an open question how frequently this is used. But like implicit
 tuple destructuring, it currently Just Works(TM) and users may not realize
 they’re making use of the feature until it’s gone.


 It's much much less used, by looking at open source projects I doubt
 that a significant portion of projects would have to change code because of
 this.

>>>
>>> The reason that I’m urging caution is because, if I recall correctly,
>>> that is also what we said about SE-0110 on this list. Then, as now, we were
>>> discussing an issue with something left over from the Swift 1 model of
>>> tuples. Then, as now, we believed that the feature in question was rarely
>>> used. Then, as now, we believed that removing that feature would improve
>>> consistency in the language, better both for the compiler and for users.
>>> Then, as now, leaving it in was thought to prevent moving forward with
>>> other features that could improve Swift.
>>>
>>>
>>> Data:
>>>
>>> I hacked up a regexp that will catch most uses of labeled tuples in
>>> pattern matches, e.g. “let (foo: bar) = baz”. That’s what we’re talking
>>> about, right?
>>>
>>>
>>> That’s 

Re: [swift-evolution] Revisiting SE-0110

[Paul Cantrell via swift-evolution]

Yes, agreed, the fix for Chris’s brain-bender shouldn’t revisit any of 
SE-0155’s matching & labeling rules.

How about:

1. Disallow labels for bare tuples in patterns. (By “bare tuples” I mean “not 
representing associated values on an enum.”)

let (a: x, b: y) = foo  // disallowed
let (x, y) = foo  // OK

2. Maybe require “let” before individual identifiers when pattern matching on 
associated values, while preserving SE-0155’s rules for when labels may appear:

case let .foo(a: x, b: y)  // disallowed
case .foo(a: let x, b: let y)  // OK

#2 is debatable. It would solve an enum-based parallel to Chris’s original:

case let .foo(a: Int, b: String)  // disallowed
case .foo(a: let Int, b: let String)  // allowed, and Int/String no 
longer look like types

P

> On Jun 16, 2017, at 10:55 PM, Xiaodi Wu  wrote:
> 
> See:
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/035972.html
>  
> 
> 
> 
> On Fri, Jun 16, 2017 at 22:32 Paul Cantrell  > wrote:
> Under these not-yet-implemented plans, if associated value labels are no 
> longer tuple labels, then how will pattern matching work? And what existing 
> pattern matching code will break / continue to work?
> 
> P
> 
>> On Jun 16, 2017, at 10:22 PM, Xiaodi Wu > > wrote:
>> 
>> Keep in mind that once the latest proposal about enum cases is implemented, 
>> these will be at least notionally no longer tuple labels but rather a 
>> sugared way of spelling part of the case name. The rules surrounding labels 
>> during case matching have only just been revised and approved and have not 
>> even yet been implemented. I don’t think it would be wise to fiddle with 
>> them again.
>> 
>> 
>> On Fri, Jun 16, 2017 at 21:21 Paul Cantrell > > wrote:
>>> On Jun 16, 2017, at 5:23 PM, Mark Lacey >> > wrote:
>>> 
>>> 
 On Jun 16, 2017, at 2:09 PM, Paul Cantrell > wrote:
 
> 
> On Jun 16, 2017, at 3:43 PM, Mark Lacey  > wrote:
> 
> 
>> On Jun 16, 2017, at 1:21 PM, Mark Lacey > > wrote:
>> 
>>> 
>>> On Jun 16, 2017, at 11:13 AM, Paul Cantrell via swift-evolution 
>>> > wrote:
>>> 
 
 On Jun 15, 2017, at 7:17 PM, Xiaodi Wu via swift-evolution 
 > wrote:
 
 
 On Thu, Jun 15, 2017 at 19:03 Víctor Pimentel > wrote:
 On 16 Jun 2017, at 01:55, Xiaodi Wu via swift-evolution 
 > wrote:
 
> On Thu, Jun 15, 2017 at 17:43 David Hart  > wrote:
> 
> By the way, I’m not attempting to deduce that nobody uses this 
> feature by the fact I didn’t know about it. But I think it’s one 
> interesting datapoint when comparing it to SE-0110.
> 
> 
> SE-0110, **in retrospect**, has had impacts on a lot of users; 
> prospectively, it was thought to be a minor change, even after review 
> and acceptance.
> 
> Keep in mind that this proposed change would also eliminate inline 
> tuple shuffle. For instance, the following code will cease to compile:
> 
> let x = (a: 1.0, r: 0.5, g: 0.5, b: 0.5)
> func f(color: (r: Double, g: Double, b: Double, a: Double)) {
>   print(color)
> }
> f(color: x)
> 
> It is an open question how frequently this is used. But like implicit 
> tuple destructuring, it currently Just Works(TM) and users may not 
> realize they’re making use of the feature until it’s gone.
 
 It's much much less used, by looking at open source projects I doubt 
 that a significant portion of projects would have to change code 
 because of this.
 
 The reason that I’m urging caution is because, if I recall correctly, 
 that is also what we said about SE-0110 on this list. Then, as now, we 
 were discussing an issue with something left over from the Swift 1 
 model of tuples. Then, as now, we believed that the feature in 
 question was rarely used. Then, as now, we believed that removing that 
 feature would improve consistency in the language, better both for the 
 compiler and for 

Re: [swift-evolution] Revisiting SE-0110

[Xiaodi Wu via swift-evolution]

See:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/035972.html


On Fri, Jun 16, 2017 at 22:32 Paul Cantrell  wrote:

> Under these not-yet-implemented plans, if associated value labels are no
> longer tuple labels, then how will pattern matching work? And what existing
> pattern matching code will break / continue to work?
>
> P
>
> On Jun 16, 2017, at 10:22 PM, Xiaodi Wu  wrote:
>
> Keep in mind that once the latest proposal about enum cases is
> implemented, these will be at least notionally no longer tuple labels but
> rather a sugared way of spelling part of the case name. The rules
> surrounding labels during case matching have only just been revised and
> approved and have not even yet been implemented. I don’t think it would be
> wise to fiddle with them again.
>
>
> On Fri, Jun 16, 2017 at 21:21 Paul Cantrell  wrote:
>
>> On Jun 16, 2017, at 5:23 PM, Mark Lacey  wrote:
>>
>>
>> On Jun 16, 2017, at 2:09 PM, Paul Cantrell  wrote:
>>
>>
>> On Jun 16, 2017, at 3:43 PM, Mark Lacey  wrote:
>>
>>
>> On Jun 16, 2017, at 1:21 PM, Mark Lacey  wrote:
>>
>>
>> On Jun 16, 2017, at 11:13 AM, Paul Cantrell via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> On Jun 15, 2017, at 7:17 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> On Thu, Jun 15, 2017 at 19:03 Víctor Pimentel 
>> wrote:
>>
>>> On 16 Jun 2017, at 01:55, Xiaodi Wu via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> On Thu, Jun 15, 2017 at 17:43 David Hart  wrote:
>>>

 By the way, I’m not attempting to deduce that nobody uses this feature
 by the fact I didn’t know about it. But I think it’s one interesting
 datapoint when comparing it to SE-0110.

>>>
>>>
>>> SE-0110, **in retrospect**, has had impacts on a lot of users;
>>> prospectively, it was thought to be a minor change, even after review and
>>> acceptance.
>>>
>>> Keep in mind that this proposed change would also eliminate inline tuple
>>> shuffle. For instance, the following code will cease to compile:
>>>
>>> let x = (a: 1.0, r: 0.5, g: 0.5, b: 0.5)
>>> func f(color: (r: Double, g: Double, b: Double, a: Double)) {
>>>   print(color)
>>> }
>>> f(color: x)
>>>
>>> It is an open question how frequently this is used. But like implicit
>>> tuple destructuring, it currently Just Works(TM) and users may not realize
>>> they’re making use of the feature until it’s gone.
>>>
>>>
>>> It's much much less used, by looking at open source projects I doubt
>>> that a significant portion of projects would have to change code because of
>>> this.
>>>
>>
>> The reason that I’m urging caution is because, if I recall correctly,
>> that is also what we said about SE-0110 on this list. Then, as now, we were
>> discussing an issue with something left over from the Swift 1 model of
>> tuples. Then, as now, we believed that the feature in question was rarely
>> used. Then, as now, we believed that removing that feature would improve
>> consistency in the language, better both for the compiler and for users.
>> Then, as now, leaving it in was thought to prevent moving forward with
>> other features that could improve Swift.
>>
>>
>> Data:
>>
>> I hacked up a regexp that will catch most uses of labeled tuples in
>> pattern matches, e.g. “let (foo: bar) = baz”. That’s what we’re talking
>> about, right?
>>
>>
>> That’s the obvious example that people find confusing.
>>
>> Less obvious places that labeled tuple patterns show up are ‘case let’
>> and ‘case’ (see below).
>>
>>
>> Okay, I should have looked at your regex and read further. It looks like
>> you were already trying to match these.
>>
>>
>> I did walk the grammar for all occurrences of _pattern_.
>>
>> I’m only matching named tuple patterns that immediately follow one of the
>> keywords which a pattern follows (for, case, let, var, and catch). As I
>> mentioned, I’m not matching patterns that come later in comma-separated
>> lists. I’m also not matching named tuples inside nested patterns, e.g. let
>> ((a: b), (c: d)).
>>
>> But again, if even the most basic form of this construct is so rare, I
>> doubt more robust matching would turn up that much more usage.
>>
>> I’m surprised you’re not seeing any uses of ‘case’ with labels.
>>
>>
>> Me too. But I just verified that my pattern does match them.
>>
>>
>> Are you sure? It doesn’t look like it’s going to match the example I gave
>> due to the leading ‘.’ on the enum case.
>>
>>
>> Ah! I should have read your original message more carefully. You’re quite
>> right, I only was checking case statements for raw tuples like this:
>>
>> case let (i: a, f: b):
>>
>> …and not for anything involving associated values. I hadn’t even
>> considered that associated values would be affected by this, but looking at
>> the 

Re: [swift-evolution] Revisiting SE-0110

[Paul Cantrell via swift-evolution]

Under these not-yet-implemented plans, if associated value labels are no longer 
tuple labels, then how will pattern matching work? And what existing pattern 
matching code will break / continue to work?

P

> On Jun 16, 2017, at 10:22 PM, Xiaodi Wu  wrote:
> 
> Keep in mind that once the latest proposal about enum cases is implemented, 
> these will be at least notionally no longer tuple labels but rather a sugared 
> way of spelling part of the case name. The rules surrounding labels during 
> case matching have only just been revised and approved and have not even yet 
> been implemented. I don’t think it would be wise to fiddle with them again.
> 
> 
> On Fri, Jun 16, 2017 at 21:21 Paul Cantrell  > wrote:
>> On Jun 16, 2017, at 5:23 PM, Mark Lacey > > wrote:
>> 
>> 
>>> On Jun 16, 2017, at 2:09 PM, Paul Cantrell >> > wrote:
>>> 
 
 On Jun 16, 2017, at 3:43 PM, Mark Lacey > wrote:
 
 
> On Jun 16, 2017, at 1:21 PM, Mark Lacey  > wrote:
> 
>> 
>> On Jun 16, 2017, at 11:13 AM, Paul Cantrell via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On Jun 15, 2017, at 7:17 PM, Xiaodi Wu via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>> On Thu, Jun 15, 2017 at 19:03 Víctor Pimentel >> > wrote:
>>> On 16 Jun 2017, at 01:55, Xiaodi Wu via swift-evolution 
>>> > wrote:
>>> 
 On Thu, Jun 15, 2017 at 17:43 David Hart > wrote:
 
 By the way, I’m not attempting to deduce that nobody uses this feature 
 by the fact I didn’t know about it. But I think it’s one interesting 
 datapoint when comparing it to SE-0110.
 
 
 SE-0110, **in retrospect**, has had impacts on a lot of users; 
 prospectively, it was thought to be a minor change, even after review 
 and acceptance.
 
 Keep in mind that this proposed change would also eliminate inline 
 tuple shuffle. For instance, the following code will cease to compile:
 
 let x = (a: 1.0, r: 0.5, g: 0.5, b: 0.5)
 func f(color: (r: Double, g: Double, b: Double, a: Double)) {
   print(color)
 }
 f(color: x)
 
 It is an open question how frequently this is used. But like implicit 
 tuple destructuring, it currently Just Works(TM) and users may not 
 realize they’re making use of the feature until it’s gone.
>>> 
>>> It's much much less used, by looking at open source projects I doubt 
>>> that a significant portion of projects would have to change code 
>>> because of this.
>>> 
>>> The reason that I’m urging caution is because, if I recall correctly, 
>>> that is also what we said about SE-0110 on this list. Then, as now, we 
>>> were discussing an issue with something left over from the Swift 1 
>>> model of tuples. Then, as now, we believed that the feature in question 
>>> was rarely used. Then, as now, we believed that removing that feature 
>>> would improve consistency in the language, better both for the compiler 
>>> and for users. Then, as now, leaving it in was thought to prevent 
>>> moving forward with other features that could improve Swift.
>> 
>> Data:
>> 
>> I hacked up a regexp that will catch most uses of labeled tuples in 
>> pattern matches, e.g. “let (foo: bar) = baz”. That’s what we’re talking 
>> about, right?
> 
> That’s the obvious example that people find confusing.
> 
> Less obvious places that labeled tuple patterns show up are ‘case let’ 
> and ‘case’ (see below). 
 
 Okay, I should have looked at your regex and read further. It looks like 
 you were already trying to match these.
>>> 
>>> I did walk the grammar for all occurrences of _pattern_.
>>> 
>>> I’m only matching named tuple patterns that immediately follow one of the 
>>> keywords which a pattern follows (for, case, let, var, and catch). As I 
>>> mentioned, I’m not matching patterns that come later in comma-separated 
>>> lists. I’m also not matching named tuples inside nested patterns, e.g. let 
>>> ((a: b), (c: d)).
>>> 
>>> But again, if even the most basic form of this construct is so rare, I 
>>> doubt more robust matching would turn up that much more usage.
>>> 
 I’m surprised you’re not seeing any uses of ‘case’ with labels.
>>> 
>>> Me too. But I just verified 

Re: [swift-evolution] Revisiting SE-0110

[Xiaodi Wu via swift-evolution]

Keep in mind that once the latest proposal about enum cases is implemented,
these will be at least notionally no longer tuple labels but rather a
sugared way of spelling part of the case name. The rules surrounding labels
during case matching have only just been revised and approved and have not
even yet been implemented. I don’t think it would be wise to fiddle with
them again.


On Fri, Jun 16, 2017 at 21:21 Paul Cantrell  wrote:

> On Jun 16, 2017, at 5:23 PM, Mark Lacey  wrote:
>
>
> On Jun 16, 2017, at 2:09 PM, Paul Cantrell  wrote:
>
>
> On Jun 16, 2017, at 3:43 PM, Mark Lacey  wrote:
>
>
> On Jun 16, 2017, at 1:21 PM, Mark Lacey  wrote:
>
>
> On Jun 16, 2017, at 11:13 AM, Paul Cantrell via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Jun 15, 2017, at 7:17 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Thu, Jun 15, 2017 at 19:03 Víctor Pimentel 
> wrote:
>
>> On 16 Jun 2017, at 01:55, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> On Thu, Jun 15, 2017 at 17:43 David Hart  wrote:
>>
>>>
>>> By the way, I’m not attempting to deduce that nobody uses this feature
>>> by the fact I didn’t know about it. But I think it’s one interesting
>>> datapoint when comparing it to SE-0110.
>>>
>>
>>
>> SE-0110, **in retrospect**, has had impacts on a lot of users;
>> prospectively, it was thought to be a minor change, even after review and
>> acceptance.
>>
>> Keep in mind that this proposed change would also eliminate inline tuple
>> shuffle. For instance, the following code will cease to compile:
>>
>> let x = (a: 1.0, r: 0.5, g: 0.5, b: 0.5)
>> func f(color: (r: Double, g: Double, b: Double, a: Double)) {
>>   print(color)
>> }
>> f(color: x)
>>
>> It is an open question how frequently this is used. But like implicit
>> tuple destructuring, it currently Just Works(TM) and users may not realize
>> they’re making use of the feature until it’s gone.
>>
>>
>> It's much much less used, by looking at open source projects I doubt that
>> a significant portion of projects would have to change code because of this.
>>
>
> The reason that I’m urging caution is because, if I recall correctly, that
> is also what we said about SE-0110 on this list. Then, as now, we were
> discussing an issue with something left over from the Swift 1 model of
> tuples. Then, as now, we believed that the feature in question was rarely
> used. Then, as now, we believed that removing that feature would improve
> consistency in the language, better both for the compiler and for users.
> Then, as now, leaving it in was thought to prevent moving forward with
> other features that could improve Swift.
>
>
> Data:
>
> I hacked up a regexp that will catch most uses of labeled tuples in
> pattern matches, e.g. “let (foo: bar) = baz”. That’s what we’re talking
> about, right?
>
>
> That’s the obvious example that people find confusing.
>
> Less obvious places that labeled tuple patterns show up are ‘case let’ and
> ‘case’ (see below).
>
>
> Okay, I should have looked at your regex and read further. It looks like
> you were already trying to match these.
>
>
> I did walk the grammar for all occurrences of _pattern_.
>
> I’m only matching named tuple patterns that immediately follow one of the
> keywords which a pattern follows (for, case, let, var, and catch). As I
> mentioned, I’m not matching patterns that come later in comma-separated
> lists. I’m also not matching named tuples inside nested patterns, e.g. let
> ((a: b), (c: d)).
>
> But again, if even the most basic form of this construct is so rare, I
> doubt more robust matching would turn up that much more usage.
>
> I’m surprised you’re not seeing any uses of ‘case’ with labels.
>
>
> Me too. But I just verified that my pattern does match them.
>
>
> Are you sure? It doesn’t look like it’s going to match the example I gave
> due to the leading ‘.’ on the enum case.
>
>
> Ah! I should have read your original message more carefully. You’re quite
> right, I only was checking case statements for raw tuples like this:
>
> case let (i: a, f: b):
>
> …and not for anything involving associated values. I hadn’t even
> considered that associated values would be affected by this, but looking at
> the grammar it seems they would indeed be.
>
> Another clumsy regex search, this time for patterns with tuple labels on
> associated values, turned up 111 results (one per ~3800 lines). Not super
> common, but certainly nothing to sneeze at. Here they are:
>
> https://gist.github.com/pcantrell/d32cdb5f7db6d6626e45e80011163efb
>
> Looking through that gist, these usages mostly strike me as being just
> fine:
>
> case .cover(from: .bottom):
>
> case .reference(with: let ref):
>
> case .update(tableName: let tableName, columnNames: _):
>
> I’d even say that removing the 

Re: [swift-evolution] Revisiting SE-0110

[Paul Cantrell via swift-evolution]

> On Jun 16, 2017, at 5:23 PM, Mark Lacey  wrote:
> 
> 
>> On Jun 16, 2017, at 2:09 PM, Paul Cantrell > > wrote:
>> 
>>> 
>>> On Jun 16, 2017, at 3:43 PM, Mark Lacey >> > wrote:
>>> 
>>> 
 On Jun 16, 2017, at 1:21 PM, Mark Lacey > wrote:
 
> 
> On Jun 16, 2017, at 11:13 AM, Paul Cantrell via swift-evolution 
> > wrote:
> 
>> 
>> On Jun 15, 2017, at 7:17 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> 
>> On Thu, Jun 15, 2017 at 19:03 Víctor Pimentel > > wrote:
>> On 16 Jun 2017, at 01:55, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>>> On Thu, Jun 15, 2017 at 17:43 David Hart >> > wrote:
>>> 
>>> By the way, I’m not attempting to deduce that nobody uses this feature 
>>> by the fact I didn’t know about it. But I think it’s one interesting 
>>> datapoint when comparing it to SE-0110.
>>> 
>>> 
>>> SE-0110, **in retrospect**, has had impacts on a lot of users; 
>>> prospectively, it was thought to be a minor change, even after review 
>>> and acceptance.
>>> 
>>> Keep in mind that this proposed change would also eliminate inline 
>>> tuple shuffle. For instance, the following code will cease to compile:
>>> 
>>> let x = (a: 1.0, r: 0.5, g: 0.5, b: 0.5)
>>> func f(color: (r: Double, g: Double, b: Double, a: Double)) {
>>>   print(color)
>>> }
>>> f(color: x)
>>> 
>>> It is an open question how frequently this is used. But like implicit 
>>> tuple destructuring, it currently Just Works(TM) and users may not 
>>> realize they’re making use of the feature until it’s gone.
>> 
>> It's much much less used, by looking at open source projects I doubt 
>> that a significant portion of projects would have to change code because 
>> of this.
>> 
>> The reason that I’m urging caution is because, if I recall correctly, 
>> that is also what we said about SE-0110 on this list. Then, as now, we 
>> were discussing an issue with something left over from the Swift 1 model 
>> of tuples. Then, as now, we believed that the feature in question was 
>> rarely used. Then, as now, we believed that removing that feature would 
>> improve consistency in the language, better both for the compiler and 
>> for users. Then, as now, leaving it in was thought to prevent moving 
>> forward with other features that could improve Swift.
> 
> Data:
> 
> I hacked up a regexp that will catch most uses of labeled tuples in 
> pattern matches, e.g. “let (foo: bar) = baz”. That’s what we’re talking 
> about, right?
 
 That’s the obvious example that people find confusing.
 
 Less obvious places that labeled tuple patterns show up are ‘case let’ and 
 ‘case’ (see below). 
>>> 
>>> Okay, I should have looked at your regex and read further. It looks like 
>>> you were already trying to match these.
>> 
>> I did walk the grammar for all occurrences of _pattern_.
>> 
>> I’m only matching named tuple patterns that immediately follow one of the 
>> keywords which a pattern follows (for, case, let, var, and catch). As I 
>> mentioned, I’m not matching patterns that come later in comma-separated 
>> lists. I’m also not matching named tuples inside nested patterns, e.g. let 
>> ((a: b), (c: d)).
>> 
>> But again, if even the most basic form of this construct is so rare, I doubt 
>> more robust matching would turn up that much more usage.
>> 
>>> I’m surprised you’re not seeing any uses of ‘case’ with labels.
>> 
>> Me too. But I just verified that my pattern does match them.
> 
> Are you sure? It doesn’t look like it’s going to match the example I gave due 
> to the leading ‘.’ on the enum case.

Ah! I should have read your original message more carefully. You’re quite 
right, I only was checking case statements for raw tuples like this:

case let (i: a, f: b):

…and not for anything involving associated values. I hadn’t even considered 
that associated values would be affected by this, but looking at the grammar it 
seems they would indeed be.

Another clumsy regex search, this time for patterns with tuple labels on 
associated values, turned up 111 results (one per ~3800 lines). Not super 
common, but certainly nothing to sneeze at. Here they are:

https://gist.github.com/pcantrell/d32cdb5f7db6d6626e45e80011163efb 


Looking through that gist, these usages mostly 

Re: [swift-evolution] Revisiting SE-0110

[Mark Lacey via swift-evolution]

> On Jun 16, 2017, at 2:09 PM, Paul Cantrell  wrote:
> 
>> 
>> On Jun 16, 2017, at 3:43 PM, Mark Lacey > > wrote:
>> 
>> 
>>> On Jun 16, 2017, at 1:21 PM, Mark Lacey >> > wrote:
>>> 
 
 On Jun 16, 2017, at 11:13 AM, Paul Cantrell via swift-evolution 
 > wrote:
 
> 
> On Jun 15, 2017, at 7:17 PM, Xiaodi Wu via swift-evolution 
> > wrote:
> 
> 
> On Thu, Jun 15, 2017 at 19:03 Víctor Pimentel  > wrote:
> On 16 Jun 2017, at 01:55, Xiaodi Wu via swift-evolution 
> > wrote:
> 
>> On Thu, Jun 15, 2017 at 17:43 David Hart > > wrote:
>> 
>> By the way, I’m not attempting to deduce that nobody uses this feature 
>> by the fact I didn’t know about it. But I think it’s one interesting 
>> datapoint when comparing it to SE-0110.
>> 
>> 
>> SE-0110, **in retrospect**, has had impacts on a lot of users; 
>> prospectively, it was thought to be a minor change, even after review 
>> and acceptance.
>> 
>> Keep in mind that this proposed change would also eliminate inline tuple 
>> shuffle. For instance, the following code will cease to compile:
>> 
>> let x = (a: 1.0, r: 0.5, g: 0.5, b: 0.5)
>> func f(color: (r: Double, g: Double, b: Double, a: Double)) {
>>   print(color)
>> }
>> f(color: x)
>> 
>> It is an open question how frequently this is used. But like implicit 
>> tuple destructuring, it currently Just Works(TM) and users may not 
>> realize they’re making use of the feature until it’s gone.
> 
> It's much much less used, by looking at open source projects I doubt that 
> a significant portion of projects would have to change code because of 
> this.
> 
> The reason that I’m urging caution is because, if I recall correctly, 
> that is also what we said about SE-0110 on this list. Then, as now, we 
> were discussing an issue with something left over from the Swift 1 model 
> of tuples. Then, as now, we believed that the feature in question was 
> rarely used. Then, as now, we believed that removing that feature would 
> improve consistency in the language, better both for the compiler and for 
> users. Then, as now, leaving it in was thought to prevent moving forward 
> with other features that could improve Swift.
 
 Data:
 
 I hacked up a regexp that will catch most uses of labeled tuples in 
 pattern matches, e.g. “let (foo: bar) = baz”. That’s what we’re talking 
 about, right?
>>> 
>>> That’s the obvious example that people find confusing.
>>> 
>>> Less obvious places that labeled tuple patterns show up are ‘case let’ and 
>>> ‘case’ (see below). 
>> 
>> Okay, I should have looked at your regex and read further. It looks like you 
>> were already trying to match these.
> 
> I did walk the grammar for all occurrences of _pattern_.
> 
> I’m only matching named tuple patterns that immediately follow one of the 
> keywords which a pattern follows (for, case, let, var, and catch). As I 
> mentioned, I’m not matching patterns that come later in comma-separated 
> lists. I’m also not matching named tuples inside nested patterns, e.g. let 
> ((a: b), (c: d)).
> 
> But again, if even the most basic form of this construct is so rare, I doubt 
> more robust matching would turn up that much more usage.
> 
>> I’m surprised you’re not seeing any uses of ‘case’ with labels.
> 
> Me too. But I just verified that my pattern does match them.

Are you sure? It doesn’t look like it’s going to match the example I gave due 
to the leading ‘.’ on the enum case.

You might want to try the patch I sent as it will definitely catch any tuple 
pattern that makes it to the verifier and does have labels.

Mark

> 
> P
> 
>> 
>> Mark
>> 
>>> Fortunately we do not appear to allow shuffling in these cases. I’m not 
>>> sure if the human disambiguation is easier here because of the context 
>>> (‘case let’ and ‘case’), but I don’t recall seeing complain about these 
>>> being confusing (having said that it’s entirely possible they are very 
>>> confusing the first time someone sees them, in particular ‘cast let’ and 
>>> the binding form of ‘case’.
>>> 
>>> enum X {
>>>   case e(i: Int, f: Float)
>>> }
>>> 
>>> let x = X.e(i: 7, f: 12)
>>> 
>>> if case let X.e(i: hi, f: bye) = x {
>>>   print("(i: \(hi), f: \(bye))")
>>> }
>>> 
>>> func test(_ x: X, _ a: Int, _ b: Float) {
>>>   switch x {
>>>   case .e(i: a, f: b):
>>> print("match values")
>>>   case .e(i: let _, f: let _):
>>> print("bind values")
>>>   

Re: [swift-evolution] Revisiting SE-0110

[Paul Cantrell via swift-evolution]

> On Jun 16, 2017, at 3:43 PM, Mark Lacey  wrote:
> 
> 
>> On Jun 16, 2017, at 1:21 PM, Mark Lacey > > wrote:
>> 
>>> 
>>> On Jun 16, 2017, at 11:13 AM, Paul Cantrell via swift-evolution 
>>> > wrote:
>>> 
 
 On Jun 15, 2017, at 7:17 PM, Xiaodi Wu via swift-evolution 
 > wrote:
 
 
 On Thu, Jun 15, 2017 at 19:03 Víctor Pimentel > wrote:
 On 16 Jun 2017, at 01:55, Xiaodi Wu via swift-evolution 
 > wrote:
 
> On Thu, Jun 15, 2017 at 17:43 David Hart  > wrote:
> 
> By the way, I’m not attempting to deduce that nobody uses this feature by 
> the fact I didn’t know about it. But I think it’s one interesting 
> datapoint when comparing it to SE-0110.
> 
> 
> SE-0110, **in retrospect**, has had impacts on a lot of users; 
> prospectively, it was thought to be a minor change, even after review and 
> acceptance.
> 
> Keep in mind that this proposed change would also eliminate inline tuple 
> shuffle. For instance, the following code will cease to compile:
> 
> let x = (a: 1.0, r: 0.5, g: 0.5, b: 0.5)
> func f(color: (r: Double, g: Double, b: Double, a: Double)) {
>   print(color)
> }
> f(color: x)
> 
> It is an open question how frequently this is used. But like implicit 
> tuple destructuring, it currently Just Works(TM) and users may not 
> realize they’re making use of the feature until it’s gone.
 
 It's much much less used, by looking at open source projects I doubt that 
 a significant portion of projects would have to change code because of 
 this.
 
 The reason that I’m urging caution is because, if I recall correctly, that 
 is also what we said about SE-0110 on this list. Then, as now, we were 
 discussing an issue with something left over from the Swift 1 model of 
 tuples. Then, as now, we believed that the feature in question was rarely 
 used. Then, as now, we believed that removing that feature would improve 
 consistency in the language, better both for the compiler and for users. 
 Then, as now, leaving it in was thought to prevent moving forward with 
 other features that could improve Swift.
>>> 
>>> Data:
>>> 
>>> I hacked up a regexp that will catch most uses of labeled tuples in pattern 
>>> matches, e.g. “let (foo: bar) = baz”. That’s what we’re talking about, 
>>> right?
>> 
>> That’s the obvious example that people find confusing.
>> 
>> Less obvious places that labeled tuple patterns show up are ‘case let’ and 
>> ‘case’ (see below).
> 
> Okay, I should have looked at your regex and read further. It looks like you 
> were already trying to match these.

I did walk the grammar for all occurrences of _pattern_.

I’m only matching named tuple patterns that immediately follow one of the 
keywords which a pattern follows (for, case, let, var, and catch). As I 
mentioned, I’m not matching patterns that come later in comma-separated lists. 
I’m also not matching named tuples inside nested patterns, e.g. let ((a: b), 
(c: d)).

But again, if even the most basic form of this construct is so rare, I doubt 
more robust matching would turn up that much more usage.

> I’m surprised you’re not seeing any uses of ‘case’ with labels.

Me too. But I just verified that my pattern does match them.

P

> 
> Mark
> 
>> Fortunately we do not appear to allow shuffling in these cases. I’m not sure 
>> if the human disambiguation is easier here because of the context (‘case 
>> let’ and ‘case’), but I don’t recall seeing complain about these being 
>> confusing (having said that it’s entirely possible they are very confusing 
>> the first time someone sees them, in particular ‘cast let’ and the binding 
>> form of ‘case’.
>> 
>> enum X {
>>   case e(i: Int, f: Float)
>> }
>> 
>> let x = X.e(i: 7, f: 12)
>> 
>> if case let X.e(i: hi, f: bye) = x {
>>   print("(i: \(hi), f: \(bye))")
>> }
>> 
>> func test(_ x: X, _ a: Int, _ b: Float) {
>>   switch x {
>>   case .e(i: a, f: b):
>> print("match values")
>>   case .e(i: let _, f: let _):
>> print("bind values")
>>   default:
>> break
>>   }
>> }
>> 
>> test(X.e(i: 1, f: 2), 1, 2)
>> test(X.e(i: 1, f: 2), 3, 4)
>> 
>> 
>>> 
>>> I ran that against all 55 projects in swift-source-compat-suite, comprising 
>>> about over 400,000 lines of Swift code, and found … drumroll … exactly one 
>>> match:
>>> 
>>> 
>>> neota (swift-source-compat-suite)$ find project_cache -name '*.swift' 
>>> -print0 | xargs -0 pcregrep -M 
>>> '(for|case|let|var|catch)\s+\([a-zA-Z0-9_]+\s*:'
>>> 

Re: [swift-evolution] Revisiting SE-0110

[Mark Lacey via swift-evolution]

> On Jun 16, 2017, at 1:21 PM, Mark Lacey  wrote:
> 
>> 
>> On Jun 16, 2017, at 11:13 AM, Paul Cantrell via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On Jun 15, 2017, at 7:17 PM, Xiaodi Wu via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>> On Thu, Jun 15, 2017 at 19:03 Víctor Pimentel >> > wrote:
>>> On 16 Jun 2017, at 01:55, Xiaodi Wu via swift-evolution 
>>> > wrote:
>>> 
 On Thu, Jun 15, 2017 at 17:43 David Hart > wrote:
 
 By the way, I’m not attempting to deduce that nobody uses this feature by 
 the fact I didn’t know about it. But I think it’s one interesting 
 datapoint when comparing it to SE-0110.
 
 
 SE-0110, **in retrospect**, has had impacts on a lot of users; 
 prospectively, it was thought to be a minor change, even after review and 
 acceptance.
 
 Keep in mind that this proposed change would also eliminate inline tuple 
 shuffle. For instance, the following code will cease to compile:
 
 let x = (a: 1.0, r: 0.5, g: 0.5, b: 0.5)
 func f(color: (r: Double, g: Double, b: Double, a: Double)) {
   print(color)
 }
 f(color: x)
 
 It is an open question how frequently this is used. But like implicit 
 tuple destructuring, it currently Just Works(TM) and users may not realize 
 they’re making use of the feature until it’s gone.
>>> 
>>> It's much much less used, by looking at open source projects I doubt that a 
>>> significant portion of projects would have to change code because of this.
>>> 
>>> The reason that I’m urging caution is because, if I recall correctly, that 
>>> is also what we said about SE-0110 on this list. Then, as now, we were 
>>> discussing an issue with something left over from the Swift 1 model of 
>>> tuples. Then, as now, we believed that the feature in question was rarely 
>>> used. Then, as now, we believed that removing that feature would improve 
>>> consistency in the language, better both for the compiler and for users. 
>>> Then, as now, leaving it in was thought to prevent moving forward with 
>>> other features that could improve Swift.
>> 
>> Data:
>> 
>> I hacked up a regexp that will catch most uses of labeled tuples in pattern 
>> matches, e.g. “let (foo: bar) = baz”. That’s what we’re talking about, right?
> 
> That’s the obvious example that people find confusing.
> 
> Less obvious places that labeled tuple patterns show up are ‘case let’ and 
> ‘case’ (see below).

Okay, I should have looked at your regex and read further. It looks like you 
were already trying to match these.

I’m surprised you’re not seeing any uses of ‘case’ with labels.

Mark

> Fortunately we do not appear to allow shuffling in these cases. I’m not sure 
> if the human disambiguation is easier here because of the context (‘case let’ 
> and ‘case’), but I don’t recall seeing complain about these being confusing 
> (having said that it’s entirely possible they are very confusing the first 
> time someone sees them, in particular ‘cast let’ and the binding form of 
> ‘case’.
> 
> enum X {
>   case e(i: Int, f: Float)
> }
> 
> let x = X.e(i: 7, f: 12)
> 
> if case let X.e(i: hi, f: bye) = x {
>   print("(i: \(hi), f: \(bye))")
> }
> 
> func test(_ x: X, _ a: Int, _ b: Float) {
>   switch x {
>   case .e(i: a, f: b):
> print("match values")
>   case .e(i: let _, f: let _):
> print("bind values")
>   default:
> break
>   }
> }
> 
> test(X.e(i: 1, f: 2), 1, 2)
> test(X.e(i: 1, f: 2), 3, 4)
> 
> 
>> 
>> I ran that against all 55 projects in swift-source-compat-suite, comprising 
>> about over 400,000 lines of Swift code, and found … drumroll … exactly one 
>> match:
>> 
>> 
>> neota (swift-source-compat-suite)$ find project_cache -name '*.swift' 
>> -print0 | xargs -0 pcregrep -M 
>> '(for|case|let|var|catch)\s+\([a-zA-Z0-9_]+\s*:'
>> project_cache/RxSwift/RxExample/RxExample-iOSTests/TestScheduler+MarbleTests.swift:
>> let (time: _, events: events) = segments.reduce((time: 0, 
>> events: [RecordedEvent]())) { state, event in
>> 
>> 
>> Caveats about this method:
>> 
>> • My regexp won’t match second and third patterns in a comma-separated let 
>> or case, e.g.:
>> 
>>let a = b, (c: d) = e
>> 
>> • It doesn’t match non-ascii identifiers.
>> 
>> • This experiment only considers labeled tuples in pattern matches, what I 
>> took Chris’s original puzzler to be about. Label-based tuple shuffling is a 
>> separate question.
>> 
>> Still, even if it’s undercounting slightly, one breakage in half a million 
>> lines of code should put to rest concerns about unexpected widespread impact.
>> 
>> (Anything else I’m missing?)
>> 
>> • • •
>> 
>> Aside for those who know the 

Re: [swift-evolution] Revisiting SE-0110

[Mark Lacey via swift-evolution]

> On Jun 16, 2017, at 11:13 AM, Paul Cantrell via swift-evolution 
>  wrote:
> 
>> 
>> On Jun 15, 2017, at 7:17 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> 
>> On Thu, Jun 15, 2017 at 19:03 Víctor Pimentel > > wrote:
>> On 16 Jun 2017, at 01:55, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>>> On Thu, Jun 15, 2017 at 17:43 David Hart >> > wrote:
>>> 
>>> By the way, I’m not attempting to deduce that nobody uses this feature by 
>>> the fact I didn’t know about it. But I think it’s one interesting datapoint 
>>> when comparing it to SE-0110.
>>> 
>>> 
>>> SE-0110, **in retrospect**, has had impacts on a lot of users; 
>>> prospectively, it was thought to be a minor change, even after review and 
>>> acceptance.
>>> 
>>> Keep in mind that this proposed change would also eliminate inline tuple 
>>> shuffle. For instance, the following code will cease to compile:
>>> 
>>> let x = (a: 1.0, r: 0.5, g: 0.5, b: 0.5)
>>> func f(color: (r: Double, g: Double, b: Double, a: Double)) {
>>>   print(color)
>>> }
>>> f(color: x)
>>> 
>>> It is an open question how frequently this is used. But like implicit tuple 
>>> destructuring, it currently Just Works(TM) and users may not realize 
>>> they’re making use of the feature until it’s gone.
>> 
>> It's much much less used, by looking at open source projects I doubt that a 
>> significant portion of projects would have to change code because of this.
>> 
>> The reason that I’m urging caution is because, if I recall correctly, that 
>> is also what we said about SE-0110 on this list. Then, as now, we were 
>> discussing an issue with something left over from the Swift 1 model of 
>> tuples. Then, as now, we believed that the feature in question was rarely 
>> used. Then, as now, we believed that removing that feature would improve 
>> consistency in the language, better both for the compiler and for users. 
>> Then, as now, leaving it in was thought to prevent moving forward with other 
>> features that could improve Swift.
> 
> Data:
> 
> I hacked up a regexp that will catch most uses of labeled tuples in pattern 
> matches, e.g. “let (foo: bar) = baz”. That’s what we’re talking about, right?

That’s the obvious example that people find confusing.

Less obvious places that labeled tuple patterns show up are ‘case let’ and 
‘case’ (see below). Fortunately we do not appear to allow shuffling in these 
cases. I’m not sure if the human disambiguation is easier here because of the 
context (‘case let’ and ‘case’), but I don’t recall seeing complain about these 
being confusing (having said that it’s entirely possible they are very 
confusing the first time someone sees them, in particular ‘cast let’ and the 
binding form of ‘case’.

enum X {
  case e(i: Int, f: Float)
}

let x = X.e(i: 7, f: 12)

if case let X.e(i: hi, f: bye) = x {
  print("(i: \(hi), f: \(bye))")
}

func test(_ x: X, _ a: Int, _ b: Float) {
  switch x {
  case .e(i: a, f: b):
print("match values")
  case .e(i: let _, f: let _):
print("bind values")
  default:
break
  }
}

test(X.e(i: 1, f: 2), 1, 2)
test(X.e(i: 1, f: 2), 3, 4)


> 
> I ran that against all 55 projects in swift-source-compat-suite, comprising 
> about over 400,000 lines of Swift code, and found … drumroll … exactly one 
> match:
> 
> 
> neota (swift-source-compat-suite)$ find project_cache -name '*.swift' -print0 
> | xargs -0 pcregrep -M '(for|case|let|var|catch)\s+\([a-zA-Z0-9_]+\s*:'
> project_cache/RxSwift/RxExample/RxExample-iOSTests/TestScheduler+MarbleTests.swift:
> let (time: _, events: events) = segments.reduce((time: 0, 
> events: [RecordedEvent]())) { state, event in
> 
> 
> Caveats about this method:
> 
> • My regexp won’t match second and third patterns in a comma-separated let or 
> case, e.g.:
> 
>let a = b, (c: d) = e
> 
> • It doesn’t match non-ascii identifiers.
> 
> • This experiment only considers labeled tuples in pattern matches, what I 
> took Chris’s original puzzler to be about. Label-based tuple shuffling is a 
> separate question.
> 
> Still, even if it’s undercounting slightly, one breakage in half a million 
> lines of code should put to rest concerns about unexpected widespread impact.
> 
> (Anything else I’m missing?)
> 
> • • •
> 
> Aside for those who know the tools out there: what would it take to run 
> inspections like this against ASTs instead of using a regex? Could we 
> instrument the compiler as Brent suggested?

If you want to catch *all* of these cases then the patch below will do it by 
failing the AST verifier when it hits a pattern with labels. If you only want 
to find the plain let-binding versions of this and not the ‘case let’ and 
‘case’ ones, I’d suggest looking at the parser to see if there’s an easy 

Re: [swift-evolution] Revisiting SE-0110

[Paul Cantrell via swift-evolution]

> On Jun 15, 2017, at 7:17 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> 
> On Thu, Jun 15, 2017 at 19:03 Víctor Pimentel  > wrote:
> On 16 Jun 2017, at 01:55, Xiaodi Wu via swift-evolution 
> > wrote:
> 
>> On Thu, Jun 15, 2017 at 17:43 David Hart > > wrote:
>> 
>> By the way, I’m not attempting to deduce that nobody uses this feature by 
>> the fact I didn’t know about it. But I think it’s one interesting datapoint 
>> when comparing it to SE-0110.
>> 
>> 
>> SE-0110, **in retrospect**, has had impacts on a lot of users; 
>> prospectively, it was thought to be a minor change, even after review and 
>> acceptance.
>> 
>> Keep in mind that this proposed change would also eliminate inline tuple 
>> shuffle. For instance, the following code will cease to compile:
>> 
>> let x = (a: 1.0, r: 0.5, g: 0.5, b: 0.5)
>> func f(color: (r: Double, g: Double, b: Double, a: Double)) {
>>   print(color)
>> }
>> f(color: x)
>> 
>> It is an open question how frequently this is used. But like implicit tuple 
>> destructuring, it currently Just Works(TM) and users may not realize they’re 
>> making use of the feature until it’s gone.
> 
> It's much much less used, by looking at open source projects I doubt that a 
> significant portion of projects would have to change code because of this.
> 
> The reason that I’m urging caution is because, if I recall correctly, that is 
> also what we said about SE-0110 on this list. Then, as now, we were 
> discussing an issue with something left over from the Swift 1 model of 
> tuples. Then, as now, we believed that the feature in question was rarely 
> used. Then, as now, we believed that removing that feature would improve 
> consistency in the language, better both for the compiler and for users. 
> Then, as now, leaving it in was thought to prevent moving forward with other 
> features that could improve Swift.

Data:

I hacked up a regexp that will catch most uses of labeled tuples in pattern 
matches, e.g. “let (foo: bar) = baz”. That’s what we’re talking about, right?

I ran that against all 55 projects in swift-source-compat-suite, comprising 
about over 400,000 lines of Swift code, and found … drumroll … exactly one 
match:


neota (swift-source-compat-suite)$ find project_cache -name '*.swift' -print0 | 
xargs -0 pcregrep -M '(for|case|let|var|catch)\s+\([a-zA-Z0-9_]+\s*:'
project_cache/RxSwift/RxExample/RxExample-iOSTests/TestScheduler+MarbleTests.swift:
let (time: _, events: events) = segments.reduce((time: 0, 
events: [RecordedEvent]())) { state, event in


Caveats about this method:

• My regexp won’t match second and third patterns in a comma-separated let or 
case, e.g.:

   let a = b, (c: d) = e

• It doesn’t match non-ascii identifiers.

• This experiment only considers labeled tuples in pattern matches, what I took 
Chris’s original puzzler to be about. Label-based tuple shuffling is a separate 
question.

Still, even if it’s undercounting slightly, one breakage in half a million 
lines of code should put to rest concerns about unexpected widespread impact.

(Anything else I’m missing?)

• • •

Aside for those who know the tools out there: what would it take to run 
inspections like this against ASTs instead of using a regex? Could we 
instrument the compiler as Brent suggested? Or can SourceKit / SourceKitten 
give a full AST? Or has anybody written a Swift parser in Swift?

Cheers,

Paul

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[rintaro ishizaki via swift-evolution]

My guess is that core team is planning to accept *patterns* in closure
parameter clause. e.g.:

  let dict = ["foo": 1, "bar": 2]
  let result = dict.map { ((k, v) : (key: String, value: Int)) in ... }
   ^^ pattern

When the compiler see this expression:

  dict.map { k, v -> R in ... }

1) Always complement () for bare parameters:

  dict.map { (k, v) -> R in ... }

2) If
  a) the context type of the closure has only one parameter with tuple
type; and
  b) closure has the same number of parameters as that tuple type; and
  c) each parameter doesn't have type annotation
treat it as a tuple patten for binding:

  dict.map { ((k, v)) -> R in ... }
  ^^ pattern

3) of that tuple type:

  dict.map { ((k, v): (key: String, value: Int)) -> R in ... }

The important thing here is step 2-c. If the parameters have type
annotations:

  dict.map { (key: String, value: Int) -> R in ... }

We can't use this as a tuple pattern because of the problem we are
discussing right now. In this case, the migrator should rewrite this to:

  dict.map { ((key, value) : (key: String, value: Int)) -> R in ... }

Also, because of that, compiler should reject this confusing tuple pattern.

  dict.map { ((key: String, value: Int)) -> R in ... }
  ^




2017-06-16 14:17 GMT+09:00 David Hart via swift-evolution <
swift-evolution@swift.org>:

>
>
> On 16 Jun 2017, at 01:55, Xiaodi Wu  wrote:
>
> On Thu, Jun 15, 2017 at 17:43 David Hart  wrote:
>
>> On 16 Jun 2017, at 00:41, David Hart  wrote:
>>
>>
>> On 15 Jun 2017, at 19:28, Chris Lattner  wrote:
>>
>>
>> On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> o
>>
>> >
 >   let (a : Int, b : Float) = foo()


 I think it would be better if the compiler raised a warning whenever
 you tried to redefine a builtin type.
>>>
>>>
>>> That’s essentially my preferred solution as well, as it gets to the root
>>> of the confusion.
>>>
>>> Naming a variable the same as a type should be similar to naming a
>>> variable the same as a reserved keyword and require backticks. (A previous
>>> suggestion to enforce capitalization falls down with full Unicode support
>>> and complicates interop where imported C structures might be lowercase and
>>> constants might be all caps.) No need to treat built-in types specially;
>>> it’s equally a problem with types imported from other libraries, which can
>>> be shadowed freely today. For full source compatibility this can be a
>>> warning instead of an error–should be sufficient as long as it’s brought to
>>> the user’s attention. In fact, probably most appropriate as a warning,
>>> since the _compiler_ knows exactly what’s going on, it’s the human that
>>> might be confused.
>>>
>>>
>>> I kind of agree with all you say. But I also feel that tuple element
>>> names in patterns are very rarely used and not worth the added complexity
>>> and confusing. Going back to the old: “Would be add it to Swift if it did
>>> not exist?”, I would say no.
>>>
>>
>> That was the standard for removing features before Swift 3, but with
>> source compatibility the bar is now much higher.
>>
>>
>> Completely agreed.  My belief on this is that it is a legacy Swift 1 type
>> system capability that no one uses.  I have no data to show that though.
>>
>> Is the feature harmful?
>>
>>
>> Yes, absolutely.  The shadowing isn't the thing that bothers me, it is
>> that swift has a meaning for that very syntax in other contexts, and that
>> this is completely different meaning.  People absolutely would get confused
>> by this if they encountered it in real code that they themselves didn't
>> write, and I'm not aware of any good (non theoretical) use for it.
>>
>> My point is, not on its own it isn’t: warning on variables shadowing
>> types is sufficient to resolve the problems shown here.
>>
>>
>> Again, my concern is that this is a confusing and misleading feature
>> which complicates and potentially prevents composing other features in the
>> future.
>>
>>
>>
>> How strange that we’re talking about this issue in a thread about
>> SE-0110.
>>
>>
>> This came up in the discussion about 110 because we were exploring
>> whether it was plausible to expand the function parameter grammar to
>> support destructuring in the position where a name goes.  There are many
>> concerns about whether this is a good idea, but he existence of this in the
>> tuple destructuring pattern grammar is pretty much a showstopper.
>>
>> If anything, the response to that proposal should be a cautionary tale
>> that users can take poorly to removing features, sometimes in unanticipated
>> ways.
>>
>>
>> Agreed, it may be too late to correct this (certainly we can't outright
>> remove it in Swift 4 if someone is using it for something important).
>> However if it turns out that it really isn't used, then 

Re: [swift-evolution] Revisiting SE-0110

[David Hart via swift-evolution]

> On 16 Jun 2017, at 08:04, Xiaodi Wu  wrote:
> 
>> On Fri, Jun 16, 2017 at 12:17 AM, David Hart  wrote:
>> 
>> 
>>> On 16 Jun 2017, at 01:55, Xiaodi Wu  wrote:
>>> 
>>> On Thu, Jun 15, 2017 at 17:43 David Hart  wrote:
>> On 16 Jun 2017, at 00:41, David Hart  wrote:
>> 
>> 
>> On 15 Jun 2017, at 19:28, Chris Lattner  wrote:
>> 
>> 
>> On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution 
>>  o
>> >
>> >   let (a : Int, b : Float) = foo()
>> 
>> 
>> I think it would be better if the compiler raised a warning whenever 
>> you tried to redefine a builtin type.
> 
> That’s essentially my preferred solution as well, as it gets to the 
> root of the confusion.
> 
> Naming a variable the same as a type should be similar to naming a 
> variable the same as a reserved keyword and require backticks. (A 
> previous suggestion to enforce capitalization falls down with full 
> Unicode support and complicates interop where imported C structures 
> might be lowercase and constants might be all caps.) No need to treat 
> built-in types specially; it’s equally a problem with types imported 
> from other libraries, which can be shadowed freely today. For full 
> source compatibility this can be a warning instead of an error–should 
> be sufficient as long as it’s brought to the user’s attention. In 
> fact, probably most appropriate as a warning, since the _compiler_ 
> knows exactly what’s going on, it’s the human that might be confused.
 
 I kind of agree with all you say. But I also feel that tuple element 
 names in patterns are very rarely used and not worth the added 
 complexity and confusing. Going back to the old: “Would be add it to 
 Swift if it did not exist?”, I would say no.
>>> 
>>> That was the standard for removing features before Swift 3, but with 
>>> source compatibility the bar is now much higher.
>> 
>> Completely agreed.  My belief on this is that it is a legacy Swift 1 
>> type system capability that no one uses.  I have no data to show that 
>> though.
>> 
>>> Is the feature harmful?
>> 
>> Yes, absolutely.  The shadowing isn't the thing that bothers me, it is 
>> that swift has a meaning for that very syntax in other contexts, and 
>> that this is completely different meaning.  People absolutely would get 
>> confused by this if they encountered it in real code that they 
>> themselves didn't write, and I'm not aware of any good (non theoretical) 
>> use for it.
>> 
>>> My point is, not on its own it isn’t: warning on variables shadowing 
>>> types is sufficient to resolve the problems shown here.
>> 
>> Again, my concern is that this is a confusing and misleading feature 
>> which complicates and potentially prevents composing other features in 
>> the future.
>> 
>> 
>>> 
>>> How strange that we’re talking about this issue in a thread about 
>>> SE-0110.
>> 
>> This came up in the discussion about 110 because we were exploring 
>> whether it was plausible to expand the function parameter grammar to 
>> support destructuring in the position where a name goes.  There are many 
>> concerns about whether this is a good idea, but he existence of this in 
>> the tuple destructuring pattern grammar is pretty much a showstopper.
>> 
>>> If anything, the response to that proposal should be a cautionary tale 
>>> that users can take poorly to removing features, sometimes in 
>>> unanticipated ways.
>> 
>> Agreed, it may be too late to correct this (certainly we can't outright 
>> remove it in Swift 4 if someone is using it for something important).  
>> However if it turns out that it really isn't used, then warning about it 
>> in 4 and removing it shortly after may be possible.
> 
> And I think its difficult to make the parallel between the two. SE-0110 
> basically impacted everybody calling higher-order functions on Dictionary 
> (+ more users from libraries like RxSwift), which makes an enormous 
> proportion of the Swift community. On the other hand, despite the 
> enormous amount of time I have sinked into learning, discussing and 
> enjoying Swift, I never come upon the tuple element name syntax in 
> patterns until Robert pointed to it out on twitter several weeks ago.
 
 By the way, I’m not attempting to deduce that nobody uses this feature by 
 the fact I didn’t know about it. But I think it’s one interesting 
 datapoint when comparing it to SE-0110.
>>> 
>>> 
>>> SE-0110, **in retrospect**, has 

Re: [swift-evolution] Revisiting SE-0110

[Goffredo Marocchi via swift-evolution]

It seems to me that we have a general problem with labels and every time we 
have to push things around they break and we simply rip them out: first with 
argument labels in closures and stores functions (sigh... :/, but we may get 
labels back somehow there one day not too far from now hopefully) and now with 
tuples.

P.S.:
I keep on thinking the urge of moving so much real world code over to it before 
the language matured (were Swift 1 and 2 the right point to move production 
code en masse?) did not leave enough time for breaking changes and discussions 
about fixing remnants of choices made with Swift 1,2, and 3 may make big 
discussions like this (and access control) here more and more prevalent, but I 
may just be a laggard/Luddite ;).

Sent from my iPhone

> On 16 Jun 2017, at 07:04, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Fri, Jun 16, 2017 at 12:17 AM, David Hart  wrote:
>> 
>> 
>>> On 16 Jun 2017, at 01:55, Xiaodi Wu  wrote:
>>> 
>>> On Thu, Jun 15, 2017 at 17:43 David Hart  wrote:
>> On 16 Jun 2017, at 00:41, David Hart  wrote:
>> 
>> 
>> On 15 Jun 2017, at 19:28, Chris Lattner  wrote:
>> 
>> 
>> On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution 
>>  o
>> >
>> >   let (a : Int, b : Float) = foo()
>> 
>> 
>> I think it would be better if the compiler raised a warning whenever 
>> you tried to redefine a builtin type.
> 
> That’s essentially my preferred solution as well, as it gets to the 
> root of the confusion.
> 
> Naming a variable the same as a type should be similar to naming a 
> variable the same as a reserved keyword and require backticks. (A 
> previous suggestion to enforce capitalization falls down with full 
> Unicode support and complicates interop where imported C structures 
> might be lowercase and constants might be all caps.) No need to treat 
> built-in types specially; it’s equally a problem with types imported 
> from other libraries, which can be shadowed freely today. For full 
> source compatibility this can be a warning instead of an error–should 
> be sufficient as long as it’s brought to the user’s attention. In 
> fact, probably most appropriate as a warning, since the _compiler_ 
> knows exactly what’s going on, it’s the human that might be confused.
 
 I kind of agree with all you say. But I also feel that tuple element 
 names in patterns are very rarely used and not worth the added 
 complexity and confusing. Going back to the old: “Would be add it to 
 Swift if it did not exist?”, I would say no.
>>> 
>>> That was the standard for removing features before Swift 3, but with 
>>> source compatibility the bar is now much higher.
>> 
>> Completely agreed.  My belief on this is that it is a legacy Swift 1 
>> type system capability that no one uses.  I have no data to show that 
>> though.
>> 
>>> Is the feature harmful?
>> 
>> Yes, absolutely.  The shadowing isn't the thing that bothers me, it is 
>> that swift has a meaning for that very syntax in other contexts, and 
>> that this is completely different meaning.  People absolutely would get 
>> confused by this if they encountered it in real code that they 
>> themselves didn't write, and I'm not aware of any good (non theoretical) 
>> use for it.
>> 
>>> My point is, not on its own it isn’t: warning on variables shadowing 
>>> types is sufficient to resolve the problems shown here.
>> 
>> Again, my concern is that this is a confusing and misleading feature 
>> which complicates and potentially prevents composing other features in 
>> the future.
>> 
>> 
>>> 
>>> How strange that we’re talking about this issue in a thread about 
>>> SE-0110.
>> 
>> This came up in the discussion about 110 because we were exploring 
>> whether it was plausible to expand the function parameter grammar to 
>> support destructuring in the position where a name goes.  There are many 
>> concerns about whether this is a good idea, but he existence of this in 
>> the tuple destructuring pattern grammar is pretty much a showstopper.
>> 
>>> If anything, the response to that proposal should be a cautionary tale 
>>> that users can take poorly to removing features, sometimes in 
>>> unanticipated ways.
>> 
>> Agreed, it may be too late to correct this (certainly we can't outright 
>> remove it in Swift 4 if someone is using it for something important).  
>> However if it turns out that it really isn't used, then warning about it 
>> in 4 and removing it shortly after 

Re: [swift-evolution] Revisiting SE-0110

[Xiaodi Wu via swift-evolution]

On Fri, Jun 16, 2017 at 12:17 AM, David Hart  wrote:

>
>
> On 16 Jun 2017, at 01:55, Xiaodi Wu  wrote:
>
> On Thu, Jun 15, 2017 at 17:43 David Hart  wrote:
>
>> On 16 Jun 2017, at 00:41, David Hart  wrote:
>>
>>
>> On 15 Jun 2017, at 19:28, Chris Lattner  wrote:
>>
>>
>> On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> o
>>
>> >
 >   let (a : Int, b : Float) = foo()


 I think it would be better if the compiler raised a warning whenever
 you tried to redefine a builtin type.
>>>
>>>
>>> That’s essentially my preferred solution as well, as it gets to the root
>>> of the confusion.
>>>
>>> Naming a variable the same as a type should be similar to naming a
>>> variable the same as a reserved keyword and require backticks. (A previous
>>> suggestion to enforce capitalization falls down with full Unicode support
>>> and complicates interop where imported C structures might be lowercase and
>>> constants might be all caps.) No need to treat built-in types specially;
>>> it’s equally a problem with types imported from other libraries, which can
>>> be shadowed freely today. For full source compatibility this can be a
>>> warning instead of an error–should be sufficient as long as it’s brought to
>>> the user’s attention. In fact, probably most appropriate as a warning,
>>> since the _compiler_ knows exactly what’s going on, it’s the human that
>>> might be confused.
>>>
>>>
>>> I kind of agree with all you say. But I also feel that tuple element
>>> names in patterns are very rarely used and not worth the added complexity
>>> and confusing. Going back to the old: “Would be add it to Swift if it did
>>> not exist?”, I would say no.
>>>
>>
>> That was the standard for removing features before Swift 3, but with
>> source compatibility the bar is now much higher.
>>
>>
>> Completely agreed.  My belief on this is that it is a legacy Swift 1 type
>> system capability that no one uses.  I have no data to show that though.
>>
>> Is the feature harmful?
>>
>>
>> Yes, absolutely.  The shadowing isn't the thing that bothers me, it is
>> that swift has a meaning for that very syntax in other contexts, and that
>> this is completely different meaning.  People absolutely would get confused
>> by this if they encountered it in real code that they themselves didn't
>> write, and I'm not aware of any good (non theoretical) use for it.
>>
>> My point is, not on its own it isn’t: warning on variables shadowing
>> types is sufficient to resolve the problems shown here.
>>
>>
>> Again, my concern is that this is a confusing and misleading feature
>> which complicates and potentially prevents composing other features in the
>> future.
>>
>>
>>
>> How strange that we’re talking about this issue in a thread about
>> SE-0110.
>>
>>
>> This came up in the discussion about 110 because we were exploring
>> whether it was plausible to expand the function parameter grammar to
>> support destructuring in the position where a name goes.  There are many
>> concerns about whether this is a good idea, but he existence of this in the
>> tuple destructuring pattern grammar is pretty much a showstopper.
>>
>> If anything, the response to that proposal should be a cautionary tale
>> that users can take poorly to removing features, sometimes in unanticipated
>> ways.
>>
>>
>> Agreed, it may be too late to correct this (certainly we can't outright
>> remove it in Swift 4 if someone is using it for something important).
>> However if it turns out that it really isn't used, then warning about it in
>> 4 and removing it shortly after may be possible.
>>
>>
>> And I think its difficult to make the parallel between the two. SE-0110
>> basically impacted everybody calling higher-order functions on Dictionary
>> (+ more users from libraries like RxSwift), which makes an enormous
>> proportion of the Swift community. On the other hand, despite the enormous
>> amount of time I have sinked into learning, discussing and enjoying Swift,
>> I never come upon the tuple element name syntax in patterns until Robert
>> pointed to it out on twitter several weeks ago.
>>
>>
>> By the way, I’m not attempting to deduce that nobody uses this feature by
>> the fact I didn’t know about it. But I think it’s one interesting datapoint
>> when comparing it to SE-0110.
>>
>
>
> SE-0110, **in retrospect**, has had impacts on a lot of users;
> prospectively, it was thought to be a minor change, even after review and
> acceptance.
>
> Keep in mind that this proposed change would also eliminate inline tuple
> shuffle. For instance, the following code will cease to compile:
>
> let x = (a: 1.0, r: 0.5, g: 0.5, b: 0.5)
> func f(color: (r: Double, g: Double, b: Double, a: Double)) {
>   print(color)
> }
> f(color: x)
>
> It is an open question how frequently this is used. But like implicit
> tuple destructuring, it currently Just 

Re: [swift-evolution] Revisiting SE-0110

[David Hart via swift-evolution]

> On 16 Jun 2017, at 01:55, Xiaodi Wu  wrote:
> 
> On Thu, Jun 15, 2017 at 17:43 David Hart  wrote:
 On 16 Jun 2017, at 00:41, David Hart  wrote:
 
 
 On 15 Jun 2017, at 19:28, Chris Lattner  wrote:
 
 
 On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution 
  o
 >
 >   let (a : Int, b : Float) = foo()
 
 
 I think it would be better if the compiler raised a warning whenever 
 you tried to redefine a builtin type.
>>> 
>>> That’s essentially my preferred solution as well, as it gets to the 
>>> root of the confusion.
>>> 
>>> Naming a variable the same as a type should be similar to naming a 
>>> variable the same as a reserved keyword and require backticks. (A 
>>> previous suggestion to enforce capitalization falls down with full 
>>> Unicode support and complicates interop where imported C structures 
>>> might be lowercase and constants might be all caps.) No need to treat 
>>> built-in types specially; it’s equally a problem with types imported 
>>> from other libraries, which can be shadowed freely today. For full 
>>> source compatibility this can be a warning instead of an error–should 
>>> be sufficient as long as it’s brought to the user’s attention. In fact, 
>>> probably most appropriate as a warning, since the _compiler_ knows 
>>> exactly what’s going on, it’s the human that might be confused.
>> 
>> I kind of agree with all you say. But I also feel that tuple element 
>> names in patterns are very rarely used and not worth the added 
>> complexity and confusing. Going back to the old: “Would be add it to 
>> Swift if it did not exist?”, I would say no.
> 
> That was the standard for removing features before Swift 3, but with 
> source compatibility the bar is now much higher.
 
 Completely agreed.  My belief on this is that it is a legacy Swift 1 type 
 system capability that no one uses.  I have no data to show that though.
 
> Is the feature harmful?
 
 Yes, absolutely.  The shadowing isn't the thing that bothers me, it is 
 that swift has a meaning for that very syntax in other contexts, and that 
 this is completely different meaning.  People absolutely would get 
 confused by this if they encountered it in real code that they themselves 
 didn't write, and I'm not aware of any good (non theoretical) use for it.
 
> My point is, not on its own it isn’t: warning on variables shadowing 
> types is sufficient to resolve the problems shown here.
 
 Again, my concern is that this is a confusing and misleading feature which 
 complicates and potentially prevents composing other features in the 
 future.
 
 
> 
> How strange that we’re talking about this issue in a thread about SE-0110.
 
 This came up in the discussion about 110 because we were exploring whether 
 it was plausible to expand the function parameter grammar to support 
 destructuring in the position where a name goes.  There are many concerns 
 about whether this is a good idea, but he existence of this in the tuple 
 destructuring pattern grammar is pretty much a showstopper.
 
> If anything, the response to that proposal should be a cautionary tale 
> that users can take poorly to removing features, sometimes in 
> unanticipated ways.
 
 Agreed, it may be too late to correct this (certainly we can't outright 
 remove it in Swift 4 if someone is using it for something important).  
 However if it turns out that it really isn't used, then warning about it 
 in 4 and removing it shortly after may be possible.
>>> 
>>> And I think its difficult to make the parallel between the two. SE-0110 
>>> basically impacted everybody calling higher-order functions on Dictionary 
>>> (+ more users from libraries like RxSwift), which makes an enormous 
>>> proportion of the Swift community. On the other hand, despite the enormous 
>>> amount of time I have sinked into learning, discussing and enjoying Swift, 
>>> I never come upon the tuple element name syntax in patterns until Robert 
>>> pointed to it out on twitter several weeks ago.
>> 
>> By the way, I’m not attempting to deduce that nobody uses this feature by 
>> the fact I didn’t know about it. But I think it’s one interesting datapoint 
>> when comparing it to SE-0110.
> 
> 
> SE-0110, **in retrospect**, has had impacts on a lot of users; prospectively, 
> it was thought to be a minor change, even after review and acceptance.
> 
> Keep in mind that this proposed change would also eliminate inline tuple 
> shuffle. For instance, the following code will cease to compile:
> 
> let x = (a: 1.0, r: 0.5, g: 0.5, b: 0.5)
> func f(color: (r: Double, g: Double, b: 

Re: [swift-evolution] Revisiting SE-0110

[Xiaodi Wu via swift-evolution]

On Thu, Jun 15, 2017 at 19:03 Víctor Pimentel  wrote:

> On 16 Jun 2017, at 01:55, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Thu, Jun 15, 2017 at 17:43 David Hart  wrote:
>
>> On 16 Jun 2017, at 00:41, David Hart  wrote:
>>
>>
>> On 15 Jun 2017, at 19:28, Chris Lattner  wrote:
>>
>>
>> On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> o
>>
>> >
 >   let (a : Int, b : Float) = foo()


 I think it would be better if the compiler raised a warning whenever
 you tried to redefine a builtin type.
>>>
>>>
>>> That’s essentially my preferred solution as well, as it gets to the root
>>> of the confusion.
>>>
>>> Naming a variable the same as a type should be similar to naming a
>>> variable the same as a reserved keyword and require backticks. (A previous
>>> suggestion to enforce capitalization falls down with full Unicode support
>>> and complicates interop where imported C structures might be lowercase and
>>> constants might be all caps.) No need to treat built-in types specially;
>>> it’s equally a problem with types imported from other libraries, which can
>>> be shadowed freely today. For full source compatibility this can be a
>>> warning instead of an error–should be sufficient as long as it’s brought to
>>> the user’s attention. In fact, probably most appropriate as a warning,
>>> since the _compiler_ knows exactly what’s going on, it’s the human that
>>> might be confused.
>>>
>>>
>>> I kind of agree with all you say. But I also feel that tuple element
>>> names in patterns are very rarely used and not worth the added complexity
>>> and confusing. Going back to the old: “Would be add it to Swift if it did
>>> not exist?”, I would say no.
>>>
>>
>> That was the standard for removing features before Swift 3, but with
>> source compatibility the bar is now much higher.
>>
>>
>> Completely agreed.  My belief on this is that it is a legacy Swift 1 type
>> system capability that no one uses.  I have no data to show that though.
>>
>> Is the feature harmful?
>>
>>
>> Yes, absolutely.  The shadowing isn't the thing that bothers me, it is
>> that swift has a meaning for that very syntax in other contexts, and that
>> this is completely different meaning.  People absolutely would get confused
>> by this if they encountered it in real code that they themselves didn't
>> write, and I'm not aware of any good (non theoretical) use for it.
>>
>> My point is, not on its own it isn’t: warning on variables shadowing
>> types is sufficient to resolve the problems shown here.
>>
>>
>> Again, my concern is that this is a confusing and misleading feature
>> which complicates and potentially prevents composing other features in the
>> future.
>>
>>
>>
>> How strange that we’re talking about this issue in a thread about
>> SE-0110.
>>
>>
>> This came up in the discussion about 110 because we were exploring
>> whether it was plausible to expand the function parameter grammar to
>> support destructuring in the position where a name goes.  There are many
>> concerns about whether this is a good idea, but he existence of this in the
>> tuple destructuring pattern grammar is pretty much a showstopper.
>>
>> If anything, the response to that proposal should be a cautionary tale
>> that users can take poorly to removing features, sometimes in unanticipated
>> ways.
>>
>>
>> Agreed, it may be too late to correct this (certainly we can't outright
>> remove it in Swift 4 if someone is using it for something important).
>> However if it turns out that it really isn't used, then warning about it in
>> 4 and removing it shortly after may be possible.
>>
>>
>> And I think its difficult to make the parallel between the two. SE-0110
>> basically impacted everybody calling higher-order functions on Dictionary
>> (+ more users from libraries like RxSwift), which makes an enormous
>> proportion of the Swift community. On the other hand, despite the enormous
>> amount of time I have sinked into learning, discussing and enjoying Swift,
>> I never come upon the tuple element name syntax in patterns until Robert
>> pointed to it out on twitter several weeks ago.
>>
>>
>> By the way, I’m not attempting to deduce that nobody uses this feature by
>> the fact I didn’t know about it. But I think it’s one interesting datapoint
>> when comparing it to SE-0110.
>>
>
>
> SE-0110, **in retrospect**, has had impacts on a lot of users;
> prospectively, it was thought to be a minor change, even after review and
> acceptance.
>
> Keep in mind that this proposed change would also eliminate inline tuple
> shuffle. For instance, the following code will cease to compile:
>
> let x = (a: 1.0, r: 0.5, g: 0.5, b: 0.5)
> func f(color: (r: Double, g: Double, b: Double, a: Double)) {
>   print(color)
> }
> f(color: x)
>
> It is an open question how frequently this is used. But like implicit
> tuple 

Re: [swift-evolution] Revisiting SE-0110

[Víctor Pimentel via swift-evolution]

> On 15 Jun 2017, at 06:01, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Jun 12, 2017, at 10:07 PM, Paul Cantrell  wrote:
>> 
>> What’s the status of this Chris’s double parens idea below? It garnered some 
>> positive responses, but the discussion seems to have fizzled out. Is there 
>> something needed to help nudge this along?
>> 
>> What’s the likelihood of getting this fixed before Swift 4 goes live, and 
>> the great wave of readability regressions hits?
> 
> We discussed this in the core team meeting today.  Consensus seems to be that 
> a change needs to be made to regain syntactic convenience here.  Discussion 
> was leaning towards allowing (at least) the parenthesized form, but more 
> discussion is needed.
> 
> 
> One (tangential) thing that came up is that tuple element names in tuple 
> *patterns* should probably be deprecated and removed at some point.  Without 
> looking, what variables does this declare?:
> 
>let (a : Int, b : Float) = foo()
> 
> ?

Sorry, but I'm utterly confused: the output from the Core Team meeting about 
regressions caused by restrictions imposed in SE-0110 is that... the compiler 
should add more restrictions??

--
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Víctor Pimentel via swift-evolution]

On 16 Jun 2017, at 01:55, Xiaodi Wu via swift-evolution 
 wrote:
> 
> On Thu, Jun 15, 2017 at 17:43 David Hart  wrote:
 On 16 Jun 2017, at 00:41, David Hart  wrote:
 
 
 On 15 Jun 2017, at 19:28, Chris Lattner  wrote:
 
 
 On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution 
  o
 >
 >   let (a : Int, b : Float) = foo()
 
 
 I think it would be better if the compiler raised a warning whenever 
 you tried to redefine a builtin type.
>>> 
>>> That’s essentially my preferred solution as well, as it gets to the 
>>> root of the confusion.
>>> 
>>> Naming a variable the same as a type should be similar to naming a 
>>> variable the same as a reserved keyword and require backticks. (A 
>>> previous suggestion to enforce capitalization falls down with full 
>>> Unicode support and complicates interop where imported C structures 
>>> might be lowercase and constants might be all caps.) No need to treat 
>>> built-in types specially; it’s equally a problem with types imported 
>>> from other libraries, which can be shadowed freely today. For full 
>>> source compatibility this can be a warning instead of an error–should 
>>> be sufficient as long as it’s brought to the user’s attention. In fact, 
>>> probably most appropriate as a warning, since the _compiler_ knows 
>>> exactly what’s going on, it’s the human that might be confused.
>> 
>> I kind of agree with all you say. But I also feel that tuple element 
>> names in patterns are very rarely used and not worth the added 
>> complexity and confusing. Going back to the old: “Would be add it to 
>> Swift if it did not exist?”, I would say no.
> 
> That was the standard for removing features before Swift 3, but with 
> source compatibility the bar is now much higher.
 
 Completely agreed.  My belief on this is that it is a legacy Swift 1 type 
 system capability that no one uses.  I have no data to show that though.
 
> Is the feature harmful?
 
 Yes, absolutely.  The shadowing isn't the thing that bothers me, it is 
 that swift has a meaning for that very syntax in other contexts, and that 
 this is completely different meaning.  People absolutely would get 
 confused by this if they encountered it in real code that they themselves 
 didn't write, and I'm not aware of any good (non theoretical) use for it.
 
> My point is, not on its own it isn’t: warning on variables shadowing 
> types is sufficient to resolve the problems shown here.
 
 Again, my concern is that this is a confusing and misleading feature which 
 complicates and potentially prevents composing other features in the 
 future.
 
 
> 
> How strange that we’re talking about this issue in a thread about SE-0110.
 
 This came up in the discussion about 110 because we were exploring whether 
 it was plausible to expand the function parameter grammar to support 
 destructuring in the position where a name goes.  There are many concerns 
 about whether this is a good idea, but he existence of this in the tuple 
 destructuring pattern grammar is pretty much a showstopper.
 
> If anything, the response to that proposal should be a cautionary tale 
> that users can take poorly to removing features, sometimes in 
> unanticipated ways.
 
 Agreed, it may be too late to correct this (certainly we can't outright 
 remove it in Swift 4 if someone is using it for something important).  
 However if it turns out that it really isn't used, then warning about it 
 in 4 and removing it shortly after may be possible.
>>> 
>>> And I think its difficult to make the parallel between the two. SE-0110 
>>> basically impacted everybody calling higher-order functions on Dictionary 
>>> (+ more users from libraries like RxSwift), which makes an enormous 
>>> proportion of the Swift community. On the other hand, despite the enormous 
>>> amount of time I have sinked into learning, discussing and enjoying Swift, 
>>> I never come upon the tuple element name syntax in patterns until Robert 
>>> pointed to it out on twitter several weeks ago.
>> 
>> By the way, I’m not attempting to deduce that nobody uses this feature by 
>> the fact I didn’t know about it. But I think it’s one interesting datapoint 
>> when comparing it to SE-0110.
> 
> 
> SE-0110, **in retrospect**, has had impacts on a lot of users; prospectively, 
> it was thought to be a minor change, even after review and acceptance.
> 
> Keep in mind that this proposed change would also eliminate inline tuple 
> shuffle. For instance, the following code will cease to compile:
> 
> let x = (a: 1.0, r: 0.5, g: 0.5, b: 0.5)
> func f(color: (r: 

Re: [swift-evolution] Revisiting SE-0110

[Xiaodi Wu via swift-evolution]

On Thu, Jun 15, 2017 at 17:43 David Hart  wrote:

> On 16 Jun 2017, at 00:41, David Hart  wrote:
>
>
> On 15 Jun 2017, at 19:28, Chris Lattner  wrote:
>
>
> On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> o
>
> >
>>> >   let (a : Int, b : Float) = foo()
>>>
>>>
>>> I think it would be better if the compiler raised a warning whenever you
>>> tried to redefine a builtin type.
>>
>>
>> That’s essentially my preferred solution as well, as it gets to the root
>> of the confusion.
>>
>> Naming a variable the same as a type should be similar to naming a
>> variable the same as a reserved keyword and require backticks. (A previous
>> suggestion to enforce capitalization falls down with full Unicode support
>> and complicates interop where imported C structures might be lowercase and
>> constants might be all caps.) No need to treat built-in types specially;
>> it’s equally a problem with types imported from other libraries, which can
>> be shadowed freely today. For full source compatibility this can be a
>> warning instead of an error–should be sufficient as long as it’s brought to
>> the user’s attention. In fact, probably most appropriate as a warning,
>> since the _compiler_ knows exactly what’s going on, it’s the human that
>> might be confused.
>>
>>
>> I kind of agree with all you say. But I also feel that tuple element
>> names in patterns are very rarely used and not worth the added complexity
>> and confusing. Going back to the old: “Would be add it to Swift if it did
>> not exist?”, I would say no.
>>
>
> That was the standard for removing features before Swift 3, but with
> source compatibility the bar is now much higher.
>
>
> Completely agreed.  My belief on this is that it is a legacy Swift 1 type
> system capability that no one uses.  I have no data to show that though.
>
> Is the feature harmful?
>
>
> Yes, absolutely.  The shadowing isn't the thing that bothers me, it is
> that swift has a meaning for that very syntax in other contexts, and that
> this is completely different meaning.  People absolutely would get confused
> by this if they encountered it in real code that they themselves didn't
> write, and I'm not aware of any good (non theoretical) use for it.
>
> My point is, not on its own it isn’t: warning on variables shadowing types
> is sufficient to resolve the problems shown here.
>
>
> Again, my concern is that this is a confusing and misleading feature which
> complicates and potentially prevents composing other features in the future.
>
>
>
> How strange that we’re talking about this issue in a thread about SE-0110.
>
>
> This came up in the discussion about 110 because we were exploring whether
> it was plausible to expand the function parameter grammar to support
> destructuring in the position where a name goes.  There are many concerns
> about whether this is a good idea, but he existence of this in the tuple
> destructuring pattern grammar is pretty much a showstopper.
>
> If anything, the response to that proposal should be a cautionary tale
> that users can take poorly to removing features, sometimes in unanticipated
> ways.
>
>
> Agreed, it may be too late to correct this (certainly we can't outright
> remove it in Swift 4 if someone is using it for something important).
> However if it turns out that it really isn't used, then warning about it in
> 4 and removing it shortly after may be possible.
>
>
> And I think its difficult to make the parallel between the two. SE-0110
> basically impacted everybody calling higher-order functions on Dictionary
> (+ more users from libraries like RxSwift), which makes an enormous
> proportion of the Swift community. On the other hand, despite the enormous
> amount of time I have sinked into learning, discussing and enjoying Swift,
> I never come upon the tuple element name syntax in patterns until Robert
> pointed to it out on twitter several weeks ago.
>
>
> By the way, I’m not attempting to deduce that nobody uses this feature by
> the fact I didn’t know about it. But I think it’s one interesting datapoint
> when comparing it to SE-0110.
>


SE-0110, **in retrospect**, has had impacts on a lot of users;
prospectively, it was thought to be a minor change, even after review and
acceptance.

Keep in mind that this proposed change would also eliminate inline tuple
shuffle. For instance, the following code will cease to compile:

let x = (a: 1.0, r: 0.5, g: 0.5, b: 0.5)
func f(color: (r: Double, g: Double, b: Double, a: Double)) {
  print(color)
}
f(color: x)

It is an open question how frequently this is used. But like implicit tuple
destructuring, it currently Just Works(TM) and users may not realize
they’re making use of the feature until it’s gone.



> -Chris
>
>
> `let (a : Int, b : Float) = foo()` is confusing but if you were to use
>>> your own type (e.g., `struct S {}` and replace Int and Float with S) you
>>> would get a compiler 

Re: [swift-evolution] Revisiting SE-0110

[Brent Royal-Gordon via swift-evolution]

> On Jun 15, 2017, at 10:28 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> My belief on this is that it is a legacy Swift 1 type system capability that 
> no one uses.  I have no data to show that though.


Tangential and perhaps a terrible idea, but: It's 2017. Can we instrument the 
compiler to tell us which weird, rare features people actually use?

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[David Hart via swift-evolution]

> On 16 Jun 2017, at 00:41, David Hart  wrote:
> 
> 
>> On 15 Jun 2017, at 19:28, Chris Lattner > > wrote:
>> 
>> 
>> On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution 
>> > o
 >
 >   let (a : Int, b : Float) = foo()
 
 
 I think it would be better if the compiler raised a warning whenever you 
 tried to redefine a builtin type.
 
 That’s essentially my preferred solution as well, as it gets to the root 
 of the confusion.
 
 Naming a variable the same as a type should be similar to naming a 
 variable the same as a reserved keyword and require backticks. (A previous 
 suggestion to enforce capitalization falls down with full Unicode support 
 and complicates interop where imported C structures might be lowercase and 
 constants might be all caps.) No need to treat built-in types specially; 
 it’s equally a problem with types imported from other libraries, which can 
 be shadowed freely today. For full source compatibility this can be a 
 warning instead of an error–should be sufficient as long as it’s brought 
 to the user’s attention. In fact, probably most appropriate as a warning, 
 since the _compiler_ knows exactly what’s going on, it’s the human that 
 might be confused.
>>> 
>>> I kind of agree with all you say. But I also feel that tuple element names 
>>> in patterns are very rarely used and not worth the added complexity and 
>>> confusing. Going back to the old: “Would be add it to Swift if it did not 
>>> exist?”, I would say no.
>>> 
>>> That was the standard for removing features before Swift 3, but with source 
>>> compatibility the bar is now much higher.
>> 
>> Completely agreed.  My belief on this is that it is a legacy Swift 1 type 
>> system capability that no one uses.  I have no data to show that though.
>> 
>>> Is the feature harmful?
>> 
>> Yes, absolutely.  The shadowing isn't the thing that bothers me, it is that 
>> swift has a meaning for that very syntax in other contexts, and that this is 
>> completely different meaning.  People absolutely would get confused by this 
>> if they encountered it in real code that they themselves didn't write, and 
>> I'm not aware of any good (non theoretical) use for it.
>> 
>>> My point is, not on its own it isn’t: warning on variables shadowing types 
>>> is sufficient to resolve the problems shown here.
>> 
>> Again, my concern is that this is a confusing and misleading feature which 
>> complicates and potentially prevents composing other features in the future.
>> 
>> 
>>> 
>>> How strange that we’re talking about this issue in a thread about SE-0110.
>> 
>> This came up in the discussion about 110 because we were exploring whether 
>> it was plausible to expand the function parameter grammar to support 
>> destructuring in the position where a name goes.  There are many concerns 
>> about whether this is a good idea, but he existence of this in the tuple 
>> destructuring pattern grammar is pretty much a showstopper.
>> 
>>> If anything, the response to that proposal should be a cautionary tale that 
>>> users can take poorly to removing features, sometimes in unanticipated ways.
>> 
>> Agreed, it may be too late to correct this (certainly we can't outright 
>> remove it in Swift 4 if someone is using it for something important).  
>> However if it turns out that it really isn't used, then warning about it in 
>> 4 and removing it shortly after may be possible.
> 
> And I think its difficult to make the parallel between the two. SE-0110 
> basically impacted everybody calling higher-order functions on Dictionary (+ 
> more users from libraries like RxSwift), which makes an enormous proportion 
> of the Swift community. On the other hand, despite the enormous amount of 
> time I have sinked into learning, discussing and enjoying Swift, I never come 
> upon the tuple element name syntax in patterns until Robert pointed to it out 
> on twitter several weeks ago.

By the way, I’m not attempting to deduce that nobody uses this feature by the 
fact I didn’t know about it. But I think it’s one interesting datapoint when 
comparing it to SE-0110.

>> -Chris
>> 
>>> 
 `let (a : Int, b : Float) = foo()` is confusing but if you were to use 
 your own type (e.g., `struct S {}` and replace Int and Float with S) you 
 would get a compiler error. If the compiler warned you that you were 
 reassigning Int and Float, you’d probably avoid that problem. Or, for a 
 more extreme fix, we could make reassigning builtin types illegal since 
 there is pretty much no valid reason to do that.
 
 
 > On Jun 15, 2017, at 8:10 AM, Matthew Johnson via swift-evolution 
 > > wrote:
 >
 >
 >
 > Sent from my iPad
 >
 >> On Jun 14, 

Re: [swift-evolution] Revisiting SE-0110

[David Hart via swift-evolution]

> On 15 Jun 2017, at 19:28, Chris Lattner  wrote:
> 
> 
> On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution 
> > o
>>> >
>>> >   let (a : Int, b : Float) = foo()
>>> 
>>> 
>>> I think it would be better if the compiler raised a warning whenever you 
>>> tried to redefine a builtin type.
>>> 
>>> That’s essentially my preferred solution as well, as it gets to the root of 
>>> the confusion.
>>> 
>>> Naming a variable the same as a type should be similar to naming a variable 
>>> the same as a reserved keyword and require backticks. (A previous 
>>> suggestion to enforce capitalization falls down with full Unicode support 
>>> and complicates interop where imported C structures might be lowercase and 
>>> constants might be all caps.) No need to treat built-in types specially; 
>>> it’s equally a problem with types imported from other libraries, which can 
>>> be shadowed freely today. For full source compatibility this can be a 
>>> warning instead of an error–should be sufficient as long as it’s brought to 
>>> the user’s attention. In fact, probably most appropriate as a warning, 
>>> since the _compiler_ knows exactly what’s going on, it’s the human that 
>>> might be confused.
>> 
>> I kind of agree with all you say. But I also feel that tuple element names 
>> in patterns are very rarely used and not worth the added complexity and 
>> confusing. Going back to the old: “Would be add it to Swift if it did not 
>> exist?”, I would say no.
>> 
>> That was the standard for removing features before Swift 3, but with source 
>> compatibility the bar is now much higher.
> 
> Completely agreed.  My belief on this is that it is a legacy Swift 1 type 
> system capability that no one uses.  I have no data to show that though.
> 
>> Is the feature harmful?
> 
> Yes, absolutely.  The shadowing isn't the thing that bothers me, it is that 
> swift has a meaning for that very syntax in other contexts, and that this is 
> completely different meaning.  People absolutely would get confused by this 
> if they encountered it in real code that they themselves didn't write, and 
> I'm not aware of any good (non theoretical) use for it.
> 
>> My point is, not on its own it isn’t: warning on variables shadowing types 
>> is sufficient to resolve the problems shown here.
> 
> Again, my concern is that this is a confusing and misleading feature which 
> complicates and potentially prevents composing other features in the future.
> 
> 
>> 
>> How strange that we’re talking about this issue in a thread about SE-0110.
> 
> This came up in the discussion about 110 because we were exploring whether it 
> was plausible to expand the function parameter grammar to support 
> destructuring in the position where a name goes.  There are many concerns 
> about whether this is a good idea, but he existence of this in the tuple 
> destructuring pattern grammar is pretty much a showstopper.
> 
>> If anything, the response to that proposal should be a cautionary tale that 
>> users can take poorly to removing features, sometimes in unanticipated ways.
> 
> Agreed, it may be too late to correct this (certainly we can't outright 
> remove it in Swift 4 if someone is using it for something important).  
> However if it turns out that it really isn't used, then warning about it in 4 
> and removing it shortly after may be possible.

And I think its difficult to make the parallel between the two. SE-0110 
basically impacted everybody calling higher-order functions on Dictionary (+ 
more users from libraries like RxSwift), which makes an enormous proportion of 
the Swift community. On the other hand, despite the enormous amount of time I 
have sinked into learning, discussing and enjoying Swift, I never come upon the 
tuple element name syntax in patterns until Robert pointed to it out on twitter 
several weeks ago.

> -Chris
> 
>> 
>>> `let (a : Int, b : Float) = foo()` is confusing but if you were to use your 
>>> own type (e.g., `struct S {}` and replace Int and Float with S) you would 
>>> get a compiler error. If the compiler warned you that you were reassigning 
>>> Int and Float, you’d probably avoid that problem. Or, for a more extreme 
>>> fix, we could make reassigning builtin types illegal since there is pretty 
>>> much no valid reason to do that.
>>> 
>>> 
>>> > On Jun 15, 2017, at 8:10 AM, Matthew Johnson via swift-evolution 
>>> > > wrote:
>>> >
>>> >
>>> >
>>> > Sent from my iPad
>>> >
>>> >> On Jun 14, 2017, at 11:01 PM, Chris Lattner via swift-evolution 
>>> >> > wrote:
>>> >>
>>> >>
>>> >>> On Jun 12, 2017, at 10:07 PM, Paul Cantrell >> >>> > wrote:
>>> >>>
>>> >>> What’s the status of this Chris’s double parens idea below? It garnered 
>>> >>> some positive responses, but 

Re: [swift-evolution] Revisiting SE-0110

[Beta via swift-evolution]

It’s not just a syntactic thing we’re talking about here.  The grammar permits 
all kinds of wonky combinations of things that will parse as “TSPL Swift", but 
will fail in Sema.  In that sense, no, this feature is not documented there.

~Robert Widmann

> On Jun 15, 2017, at 12:08 PM, Kyle Murray via swift-evolution 
>  wrote:
> 
> Yes, in the sense that the grammar 
> 
>  has a production that permits the tuple element name. But there aren't any 
> examples that use labels within patterns.
> 
> 
> GRAMMAR OF A TUPLE PATTERN
> 
>  <>tuple-pattern → (­tuple-pattern-element-list 
> ­opt­)­
>  <>tuple-pattern-element-list → tuple-pattern-element 
> ­
>| tuple-pattern-element 
> ­,­tuple-pattern-element-list
>  
> ­
>  <>tuple-pattern-element → pattern 
> ­
>|  identifier 
> ­:­pattern
>  
> ­
>  <>
> 
> -Kyle
> 
>> On Jun 15, 2017, at 10:34 AM, Chris Lattner via swift-evolution 
>> > wrote:
>> 
>> Is this capability even documented in TSPL?
> 
> ___
> 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

Re: [swift-evolution] Revisiting SE-0110

[Kyle Murray via swift-evolution]

Yes, in the sense that the grammar 

 has a production that permits the tuple element name. But there aren't any 
examples that use labels within patterns.


GRAMMAR OF A TUPLE PATTERN

 <>tuple-pattern → (­tuple-pattern-element-list 
­opt­)­
 <>tuple-pattern-element-list → tuple-pattern-element 
­
   | tuple-pattern-element 
­,­tuple-pattern-element-list
 
­
 <>tuple-pattern-element → pattern 
­
   |  identifier 
­:­pattern
 
­
 <>

-Kyle

> On Jun 15, 2017, at 10:34 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Is this capability even documented in TSPL?

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Chris Lattner via swift-evolution]

> 
> On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution 
>  o
 >
 >   let (a : Int, b : Float) = foo()
 
 
 I think it would be better if the compiler raised a warning whenever you 
 tried to redefine a builtin type.
>>> 
>>> That’s essentially my preferred solution as well, as it gets to the root of 
>>> the confusion.
>>> 
>>> Naming a variable the same as a type should be similar to naming a variable 
>>> the same as a reserved keyword and require backticks. (A previous 
>>> suggestion to enforce capitalization falls down with full Unicode support 
>>> and complicates interop where imported C structures might be lowercase and 
>>> constants might be all caps.) No need to treat built-in types specially; 
>>> it’s equally a problem with types imported from other libraries, which can 
>>> be shadowed freely today. For full source compatibility this can be a 
>>> warning instead of an error–should be sufficient as long as it’s brought to 
>>> the user’s attention. In fact, probably most appropriate as a warning, 
>>> since the _compiler_ knows exactly what’s going on, it’s the human that 
>>> might be confused.
>> 
>> I kind of agree with all you say. But I also feel that tuple element names 
>> in patterns are very rarely used and not worth the added complexity and 
>> confusing. Going back to the old: “Would be add it to Swift if it did not 
>> exist?”, I would say no.
> 
> That was the standard for removing features before Swift 3, but with source 
> compatibility the bar is now much higher.

Completely agreed.  My belief on this is that it is a legacy Swift 1 type 
system capability that no one uses.  I have no data to show that though.

> Is the feature harmful?

Yes, absolutely.  The shadowing isn't the thing that bothers me, it is that 
swift has a meaning for that very syntax in other contexts, and that this is 
completely different meaning.  People absolutely would get confused by this if 
they encountered it in real code that they themselves didn't write, and I'm not 
aware of any good (non theoretical) use for it.

> My point is, not on its own it isn’t: warning on variables shadowing types is 
> sufficient to resolve the problems shown here.

Again, my concern is that this is a confusing and misleading feature which 
complicates and potentially prevents composing other features in the future.


> 
> How strange that we’re talking about this issue in a thread about SE-0110.

This came up in the discussion about 110 because we were exploring whether it 
was plausible to expand the function parameter grammar to support destructuring 
in the position where a name goes.  There are many concerns about whether this 
is a good idea, but he existence of this in the tuple destructuring pattern 
grammar is pretty much a showstopper.

> If anything, the response to that proposal should be a cautionary tale that 
> users can take poorly to removing features, sometimes in unanticipated ways.

Agreed, it may be too late to correct this (certainly we can't outright remove 
it in Swift 4 if someone is using it for something important).  However if it 
turns out that it really isn't used, then warning about it in 4 and removing it 
shortly after may be possible.

-Chris

> 
 `let (a : Int, b : Float) = foo()` is confusing but if you were to use 
 your own type (e.g., `struct S {}` and replace Int and Float with S) you 
 would get a compiler error. If the compiler warned you that you were 
 reassigning Int and Float, you’d probably avoid that problem. Or, for a 
 more extreme fix, we could make reassigning builtin types illegal since 
 there is pretty much no valid reason to do that.
 
 
 > On Jun 15, 2017, at 8:10 AM, Matthew Johnson via swift-evolution 
 >  wrote:
 >
 >
 >
 > Sent from my iPad
 >
 >> On Jun 14, 2017, at 11:01 PM, Chris Lattner via swift-evolution 
 >>  wrote:
 >>
 >>
 >>> On Jun 12, 2017, at 10:07 PM, Paul Cantrell  wrote:
 >>>
 >>> What’s the status of this Chris’s double parens idea below? It 
 >>> garnered some positive responses, but the discussion seems to have 
 >>> fizzled out. Is there something needed to help nudge this along?
 >>>
 >>> What’s the likelihood of getting this fixed before Swift 4 goes live, 
 >>> and the great wave of readability regressions hits?
 >>
 >> We discussed this in the core team meeting today.  Consensus seems to 
 >> be that a change needs to be made to regain syntactic convenience here. 
 >>  Discussion was leaning towards allowing (at least) the parenthesized 
 >> form, but more discussion is needed.
 >>
 >>
 >> One (tangential) thing that came up is that tuple element names in 
 >> tuple *patterns* should probably be deprecated and removed at some 
 >> point.  Without looking, 

Re: [swift-evolution] Revisiting SE-0110

[Chris Lattner via swift-evolution]

> On Jun 15, 2017, at 10:28 AM, Chris Lattner  wrote:
> 
> 
>> Is the feature harmful?
> 
> Yes, absolutely.  The shadowing isn't the thing that bothers me, it is that 
> swift has a meaning for that very syntax in other contexts, and that this is 
> completely different meaning.  People absolutely would get confused by this 
> if they encountered it in real code that they themselves didn't write, and 
> I'm not aware of any good (non theoretical) use for it.

A different way to look at it: beyond enabling a dubious capability (inline 
tuple shuffle) the pattern matching syntax is arguably just backwards.  Thus it 
is inconsistent with the rest of Swift (e.g. tuple type syntax).  This makes it 
super confusing.

I recognize that by itself this isn't enough of a reason to make a change.  Is 
this capability even documented in TSPL?

-Chris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Mark Lacey via swift-evolution]

> On Jun 15, 2017, at 8:23 AM, Robert Bennett via swift-evolution 
>  wrote:
> 
>> One (tangential) thing that came up is that tuple element names in tuple 
>> *patterns* should probably be deprecated and removed at some point.  Without 
>> looking, what variables does this declare?:
>> 
>>  let (a : Int, b : Float) = foo()
> 
> 
> I think it would be better if the compiler raised a warning whenever you 
> tried to redefine a builtin type. `let (a : Int, b : Float) = foo()` is 
> confusing but if you were to use your own type (e.g., `struct S {}` and 
> replace Int and Float with S) you would get a compiler error.

If you replace *both* Int and Float with S you would get an error, but if you 
replace one you’ll only get an error if you do this within the same scope that 
your type is defined.

There’s nothing special happening here for the stdlib types vs. your own types. 
What you’re witnessing is shadowing. You can shadow names within deeper scopes, 
e.g. this is perfectly legal:

func MyOwnInt() {
  struct Int : ExpressibleByFloatLiteral {
typealias FloatLiteralType = Double

public init(floatLiteral value: FloatLiteralType) {
  self.value = value
}

var value: FloatLiteralType
  }
  let _: Int = 7.0
}


Mark

> If the compiler warned you that you were reassigning Int and Float, you’d 
> probably avoid that problem. Or, for a more extreme fix, we could make 
> reassigning builtin types illegal since there is pretty much no valid reason 
> to do that.
> 
> 
>> On Jun 15, 2017, at 8:10 AM, Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>> Sent from my iPad
>> 
>>> On Jun 14, 2017, at 11:01 PM, Chris Lattner via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On Jun 12, 2017, at 10:07 PM, Paul Cantrell  wrote:
 
 What’s the status of this Chris’s double parens idea below? It garnered 
 some positive responses, but the discussion seems to have fizzled out. Is 
 there something needed to help nudge this along?
 
 What’s the likelihood of getting this fixed before Swift 4 goes live, and 
 the great wave of readability regressions hits?
>>> 
>>> We discussed this in the core team meeting today.  Consensus seems to be 
>>> that a change needs to be made to regain syntactic convenience here.  
>>> Discussion was leaning towards allowing (at least) the parenthesized form, 
>>> but more discussion is needed.
>>> 
>>> 
>>> One (tangential) thing that came up is that tuple element names in tuple 
>>> *patterns* should probably be deprecated and removed at some point.  
>>> Without looking, what variables does this declare?:
>>> 
>>>  let (a : Int, b : Float) = foo()
>> 
>> Another option would be to require let to appear next to each name binding 
>> instead of allowing a single let for the whole pattern.  I personally find 
>> that much more clear despite it being a little bit more verbose.
>> 
>>> 
>>> ?
>>> 
>>> -Chris
>>> 
>>> ___
>>> 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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Xiaodi Wu via swift-evolution]

On Thu, Jun 15, 2017 at 11:19 David Hart  wrote:

> On 15 Jun 2017, at 18:05, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Thu, Jun 15, 2017 at 10:23 Robert Bennett via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> > One (tangential) thing that came up is that tuple element names in
>> tuple *patterns* should probably be deprecated and removed at some point.
>> Without looking, what variables does this declare?:
>> >
>> >   let (a : Int, b : Float) = foo()
>>
>>
>> I think it would be better if the compiler raised a warning whenever you
>> tried to redefine a builtin type.
>
>
> That’s essentially my preferred solution as well, as it gets to the root
> of the confusion.
>
> Naming a variable the same as a type should be similar to naming a
> variable the same as a reserved keyword and require backticks. (A previous
> suggestion to enforce capitalization falls down with full Unicode support
> and complicates interop where imported C structures might be lowercase and
> constants might be all caps.) No need to treat built-in types specially;
> it’s equally a problem with types imported from other libraries, which can
> be shadowed freely today. For full source compatibility this can be a
> warning instead of an error–should be sufficient as long as it’s brought to
> the user’s attention. In fact, probably most appropriate as a warning,
> since the _compiler_ knows exactly what’s going on, it’s the human that
> might be confused.
>
>
> I kind of agree with all you say. But I also feel that tuple element names
> in patterns are very rarely used and not worth the added complexity and
> confusing. Going back to the old: “Would be add it to Swift if it did not
> exist?”, I would say no.
>

That was the standard for removing features before Swift 3, but with source
compatibility the bar is now much higher. Is the feature harmful? My point
is, not on its own it isn’t: warning on variables shadowing types is
sufficient to resolve the problems shown here.

How strange that we’re talking about this issue in a thread about SE-0110.
If anything, the response to that proposal should be a cautionary tale that
users can take poorly to removing features, sometimes in unanticipated ways.

`let (a : Int, b : Float) = foo()` is confusing but if you were to use your
>> own type (e.g., `struct S {}` and replace Int and Float with S) you would
>> get a compiler error. If the compiler warned you that you were reassigning
>> Int and Float, you’d probably avoid that problem. Or, for a more extreme
>> fix, we could make reassigning builtin types illegal since there is pretty
>> much no valid reason to do that.
>>
>>
>> > On Jun 15, 2017, at 8:10 AM, Matthew Johnson via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> >
>> >
>> > Sent from my iPad
>> >
>> >> On Jun 14, 2017, at 11:01 PM, Chris Lattner via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >>
>> >>
>> >>> On Jun 12, 2017, at 10:07 PM, Paul Cantrell 
>> wrote:
>> >>>
>> >>> What’s the status of this Chris’s double parens idea below? It
>> garnered some positive responses, but the discussion seems to have fizzled
>> out. Is there something needed to help nudge this along?
>> >>>
>> >>> What’s the likelihood of getting this fixed before Swift 4 goes live,
>> and the great wave of readability regressions hits?
>> >>
>> >> We discussed this in the core team meeting today.  Consensus seems to
>> be that a change needs to be made to regain syntactic convenience here.
>> Discussion was leaning towards allowing (at least) the parenthesized form,
>> but more discussion is needed.
>> >>
>> >>
>> >> One (tangential) thing that came up is that tuple element names in
>> tuple *patterns* should probably be deprecated and removed at some point.
>> Without looking, what variables does this declare?:
>> >>
>> >>   let (a : Int, b : Float) = foo()
>> >
>> > Another option would be to require let to appear next to each name
>> binding instead of allowing a single let for the whole pattern.  I
>> personally find that much more clear despite it being a little bit more
>> verbose.
>> >
>> >>
>> >> ?
>> >>
>> >> -Chris
>> >>
>> >> ___
>> >> 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
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___

Re: [swift-evolution] Revisiting SE-0110

[David Hart via swift-evolution]

> On 15 Jun 2017, at 18:05, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Thu, Jun 15, 2017 at 10:23 Robert Bennett via swift-evolution 
> > wrote:
> > One (tangential) thing that came up is that tuple element names in tuple 
> > *patterns* should probably be deprecated and removed at some point.  
> > Without looking, what variables does this declare?:
> >
> >   let (a : Int, b : Float) = foo()
> 
> 
> I think it would be better if the compiler raised a warning whenever you 
> tried to redefine a builtin type.
> 
> That’s essentially my preferred solution as well, as it gets to the root of 
> the confusion.
> 
> Naming a variable the same as a type should be similar to naming a variable 
> the same as a reserved keyword and require backticks. (A previous suggestion 
> to enforce capitalization falls down with full Unicode support and 
> complicates interop where imported C structures might be lowercase and 
> constants might be all caps.) No need to treat built-in types specially; it’s 
> equally a problem with types imported from other libraries, which can be 
> shadowed freely today. For full source compatibility this can be a warning 
> instead of an error–should be sufficient as long as it’s brought to the 
> user’s attention. In fact, probably most appropriate as a warning, since the 
> _compiler_ knows exactly what’s going on, it’s the human that might be 
> confused.

I kind of agree with all you say. But I also feel that tuple element names in 
patterns are very rarely used and not worth the added complexity and confusing. 
Going back to the old: “Would be add it to Swift if it did not exist?”, I would 
say no.

> `let (a : Int, b : Float) = foo()` is confusing but if you were to use your 
> own type (e.g., `struct S {}` and replace Int and Float with S) you would get 
> a compiler error. If the compiler warned you that you were reassigning Int 
> and Float, you’d probably avoid that problem. Or, for a more extreme fix, we 
> could make reassigning builtin types illegal since there is pretty much no 
> valid reason to do that.
> 
> 
> > On Jun 15, 2017, at 8:10 AM, Matthew Johnson via swift-evolution 
> > > wrote:
> >
> >
> >
> > Sent from my iPad
> >
> >> On Jun 14, 2017, at 11:01 PM, Chris Lattner via swift-evolution 
> >> > wrote:
> >>
> >>
> >>> On Jun 12, 2017, at 10:07 PM, Paul Cantrell  >>> > wrote:
> >>>
> >>> What’s the status of this Chris’s double parens idea below? It garnered 
> >>> some positive responses, but the discussion seems to have fizzled out. Is 
> >>> there something needed to help nudge this along?
> >>>
> >>> What’s the likelihood of getting this fixed before Swift 4 goes live, and 
> >>> the great wave of readability regressions hits?
> >>
> >> We discussed this in the core team meeting today.  Consensus seems to be 
> >> that a change needs to be made to regain syntactic convenience here.  
> >> Discussion was leaning towards allowing (at least) the parenthesized form, 
> >> but more discussion is needed.
> >>
> >>
> >> One (tangential) thing that came up is that tuple element names in tuple 
> >> *patterns* should probably be deprecated and removed at some point.  
> >> Without looking, what variables does this declare?:
> >>
> >>   let (a : Int, b : Float) = foo()
> >
> > Another option would be to require let to appear next to each name binding 
> > instead of allowing a single let for the whole pattern.  I personally find 
> > that much more clear despite it being a little bit more verbose.
> >
> >>
> >> ?
> >>
> >> -Chris
> >>
> >> ___
> >> 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 
> 
> ___
> 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

Re: [swift-evolution] Revisiting SE-0110

[Chris Lattner via swift-evolution]

Let me clarify: I'm only talking about removing tuple element names from the 
*pattern* grammar.  They would still be allowed on tuple types, which is what 
you are using.

-Chris

> On Jun 14, 2017, at 9:45 PM, Charlie Monroe  wrote:
> 
> 
>> On Jun 15, 2017, at 6:01 AM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Jun 12, 2017, at 10:07 PM, Paul Cantrell  wrote:
>>> 
>>> What’s the status of this Chris’s double parens idea below? It garnered 
>>> some positive responses, but the discussion seems to have fizzled out. Is 
>>> there something needed to help nudge this along?
>>> 
>>> What’s the likelihood of getting this fixed before Swift 4 goes live, and 
>>> the great wave of readability regressions hits?
>> 
>> We discussed this in the core team meeting today.  Consensus seems to be 
>> that a change needs to be made to regain syntactic convenience here.  
>> Discussion was leaning towards allowing (at least) the parenthesized form, 
>> but more discussion is needed.
>> 
>> 
>> One (tangential) thing that came up is that tuple element names in tuple 
>> *patterns* should probably be deprecated and removed at some point.  Without 
>> looking, what variables does this declare?:
>> 
>>let (a : Int, b : Float) = foo()
> 
> Personally, I use this often as "anonymous structs" (which tuples IMHO are). 
> Often, there is a return type used in 1-2 methods and in such case, I feel 
> that declaring a struct MyMethorReturnStruct is unnecessary and I use tuples 
> with named elements, so that the call site can easily access the information 
> it needs, which is particularly convenient if both tuple member are of the 
> same type:
> 
> func parseName() -> (firstName: String, lastName: String)
> 
> Instead of deprecating this, would it be possible to make this a syntax for 
> generating a truly anonymous structure? It can internally have a name that 
> mangles together the element *names and types*, so:
> 
> let name = (firstName: "John", lastName: "Doe")
> 
> type(of: name) == _firstName_String_lastName_String_
> 
> Hence you would be able to pass this structure wherever it's declared exactly 
> the same, but:
> 
> func passName() -> (name1: String, name2: String) {
>return parseName() // see above for declaration
> }
> 
> will result in error as (firstName: String, lastName: String) cannot be 
> converted to (name1: String, name2: String).
> 
> 
>> 
>> ?
>> 
>> -Chris
>> 
>> ___
>> 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

Re: [swift-evolution] Revisiting SE-0110

[Xiaodi Wu via swift-evolution]

On Thu, Jun 15, 2017 at 10:23 Robert Bennett via swift-evolution <
swift-evolution@swift.org> wrote:

> > One (tangential) thing that came up is that tuple element names in tuple
> *patterns* should probably be deprecated and removed at some point.
> Without looking, what variables does this declare?:
> >
> >   let (a : Int, b : Float) = foo()
>
>
> I think it would be better if the compiler raised a warning whenever you
> tried to redefine a builtin type.


That’s essentially my preferred solution as well, as it gets to the root of
the confusion.

Naming a variable the same as a type should be similar to naming a variable
the same as a reserved keyword and require backticks. (A previous
suggestion to enforce capitalization falls down with full Unicode support
and complicates interop where imported C structures might be lowercase and
constants might be all caps.) No need to treat built-in types specially;
it’s equally a problem with types imported from other libraries, which can
be shadowed freely today. For full source compatibility this can be a
warning instead of an error–should be sufficient as long as it’s brought to
the user’s attention. In fact, probably most appropriate as a warning,
since the _compiler_ knows exactly what’s going on, it’s the human that
might be confused.

`let (a : Int, b : Float) = foo()` is confusing but if you were to use your
> own type (e.g., `struct S {}` and replace Int and Float with S) you would
> get a compiler error. If the compiler warned you that you were reassigning
> Int and Float, you’d probably avoid that problem. Or, for a more extreme
> fix, we could make reassigning builtin types illegal since there is pretty
> much no valid reason to do that.
>
>
> > On Jun 15, 2017, at 8:10 AM, Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> >
> > Sent from my iPad
> >
> >> On Jun 14, 2017, at 11:01 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >>
> >>> On Jun 12, 2017, at 10:07 PM, Paul Cantrell 
> wrote:
> >>>
> >>> What’s the status of this Chris’s double parens idea below? It
> garnered some positive responses, but the discussion seems to have fizzled
> out. Is there something needed to help nudge this along?
> >>>
> >>> What’s the likelihood of getting this fixed before Swift 4 goes live,
> and the great wave of readability regressions hits?
> >>
> >> We discussed this in the core team meeting today.  Consensus seems to
> be that a change needs to be made to regain syntactic convenience here.
> Discussion was leaning towards allowing (at least) the parenthesized form,
> but more discussion is needed.
> >>
> >>
> >> One (tangential) thing that came up is that tuple element names in
> tuple *patterns* should probably be deprecated and removed at some point.
> Without looking, what variables does this declare?:
> >>
> >>   let (a : Int, b : Float) = foo()
> >
> > Another option would be to require let to appear next to each name
> binding instead of allowing a single let for the whole pattern.  I
> personally find that much more clear despite it being a little bit more
> verbose.
> >
> >>
> >> ?
> >>
> >> -Chris
> >>
> >> ___
> >> 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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Robert Bennett via swift-evolution]

> One (tangential) thing that came up is that tuple element names in tuple 
> *patterns* should probably be deprecated and removed at some point.  Without 
> looking, what variables does this declare?:
> 
>   let (a : Int, b : Float) = foo()


I think it would be better if the compiler raised a warning whenever you tried 
to redefine a builtin type. `let (a : Int, b : Float) = foo()` is confusing but 
if you were to use your own type (e.g., `struct S {}` and replace Int and Float 
with S) you would get a compiler error. If the compiler warned you that you 
were reassigning Int and Float, you’d probably avoid that problem. Or, for a 
more extreme fix, we could make reassigning builtin types illegal since there 
is pretty much no valid reason to do that.


> On Jun 15, 2017, at 8:10 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On Jun 14, 2017, at 11:01 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Jun 12, 2017, at 10:07 PM, Paul Cantrell  wrote:
>>> 
>>> What’s the status of this Chris’s double parens idea below? It garnered 
>>> some positive responses, but the discussion seems to have fizzled out. Is 
>>> there something needed to help nudge this along?
>>> 
>>> What’s the likelihood of getting this fixed before Swift 4 goes live, and 
>>> the great wave of readability regressions hits?
>> 
>> We discussed this in the core team meeting today.  Consensus seems to be 
>> that a change needs to be made to regain syntactic convenience here.  
>> Discussion was leaning towards allowing (at least) the parenthesized form, 
>> but more discussion is needed.
>> 
>> 
>> One (tangential) thing that came up is that tuple element names in tuple 
>> *patterns* should probably be deprecated and removed at some point.  Without 
>> looking, what variables does this declare?:
>> 
>>   let (a : Int, b : Float) = foo()
> 
> Another option would be to require let to appear next to each name binding 
> instead of allowing a single let for the whole pattern.  I personally find 
> that much more clear despite it being a little bit more verbose.
> 
>> 
>> ?
>> 
>> -Chris
>> 
>> ___
>> 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

Re: [swift-evolution] Revisiting SE-0110

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jun 14, 2017, at 11:01 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Jun 12, 2017, at 10:07 PM, Paul Cantrell  wrote:
>> 
>> What’s the status of this Chris’s double parens idea below? It garnered some 
>> positive responses, but the discussion seems to have fizzled out. Is there 
>> something needed to help nudge this along?
>> 
>> What’s the likelihood of getting this fixed before Swift 4 goes live, and 
>> the great wave of readability regressions hits?
> 
> We discussed this in the core team meeting today.  Consensus seems to be that 
> a change needs to be made to regain syntactic convenience here.  Discussion 
> was leaning towards allowing (at least) the parenthesized form, but more 
> discussion is needed.
> 
> 
> One (tangential) thing that came up is that tuple element names in tuple 
> *patterns* should probably be deprecated and removed at some point.  Without 
> looking, what variables does this declare?:
> 
>let (a : Int, b : Float) = foo()

Another option would be to require let to appear next to each name binding 
instead of allowing a single let for the whole pattern.  I personally find that 
much more clear despite it being a little bit more verbose.

> 
> ?
> 
> -Chris
> 
> ___
> 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

Re: [swift-evolution] Revisiting SE-0110

[David Hart via swift-evolution]

It declares variables Int and Float, but I know that only because CodaFi asked 
us the same question on twitter a while back! I'd be very happy if that was 
deprecated.

> On 15 Jun 2017, at 06:01, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Jun 12, 2017, at 10:07 PM, Paul Cantrell  wrote:
>> 
>> What’s the status of this Chris’s double parens idea below? It garnered some 
>> positive responses, but the discussion seems to have fizzled out. Is there 
>> something needed to help nudge this along?
>> 
>> What’s the likelihood of getting this fixed before Swift 4 goes live, and 
>> the great wave of readability regressions hits?
> 
> We discussed this in the core team meeting today.  Consensus seems to be that 
> a change needs to be made to regain syntactic convenience here.  Discussion 
> was leaning towards allowing (at least) the parenthesized form, but more 
> discussion is needed.
> 
> 
> One (tangential) thing that came up is that tuple element names in tuple 
> *patterns* should probably be deprecated and removed at some point.  Without 
> looking, what variables does this declare?:
> 
>let (a : Int, b : Float) = foo()
> 
> ?
> 
> -Chris
> 
> ___
> 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

Re: [swift-evolution] Revisiting SE-0110

[Charlie Monroe via swift-evolution]

> On Jun 15, 2017, at 6:01 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Jun 12, 2017, at 10:07 PM, Paul Cantrell  wrote:
>> 
>> What’s the status of this Chris’s double parens idea below? It garnered some 
>> positive responses, but the discussion seems to have fizzled out. Is there 
>> something needed to help nudge this along?
>> 
>> What’s the likelihood of getting this fixed before Swift 4 goes live, and 
>> the great wave of readability regressions hits?
> 
> We discussed this in the core team meeting today.  Consensus seems to be that 
> a change needs to be made to regain syntactic convenience here.  Discussion 
> was leaning towards allowing (at least) the parenthesized form, but more 
> discussion is needed.
> 
> 
> One (tangential) thing that came up is that tuple element names in tuple 
> *patterns* should probably be deprecated and removed at some point.  Without 
> looking, what variables does this declare?:
> 
>   let (a : Int, b : Float) = foo()

Personally, I use this often as "anonymous structs" (which tuples IMHO are). 
Often, there is a return type used in 1-2 methods and in such case, I feel that 
declaring a struct MyMethorReturnStruct is unnecessary and I use tuples with 
named elements, so that the call site can easily access the information it 
needs, which is particularly convenient if both tuple member are of the same 
type:

func parseName() -> (firstName: String, lastName: String)

Instead of deprecating this, would it be possible to make this a syntax for 
generating a truly anonymous structure? It can internally have a name that 
mangles together the element *names and types*, so:

let name = (firstName: "John", lastName: "Doe")

type(of: name) == _firstName_String_lastName_String_

Hence you would be able to pass this structure wherever it's declared exactly 
the same, but:

func passName() -> (name1: String, name2: String) {
return parseName() // see above for declaration
}

will result in error as (firstName: String, lastName: String) cannot be 
converted to (name1: String, name2: String).


> 
> ?
> 
> -Chris
> 
> ___
> 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

Re: [swift-evolution] Revisiting SE-0110

[Chris Lattner via swift-evolution]

> On Jun 12, 2017, at 10:07 PM, Paul Cantrell  wrote:
> 
> What’s the status of this Chris’s double parens idea below? It garnered some 
> positive responses, but the discussion seems to have fizzled out. Is there 
> something needed to help nudge this along?
> 
> What’s the likelihood of getting this fixed before Swift 4 goes live, and the 
> great wave of readability regressions hits?

We discussed this in the core team meeting today.  Consensus seems to be that a 
change needs to be made to regain syntactic convenience here.  Discussion was 
leaning towards allowing (at least) the parenthesized form, but more discussion 
is needed.


One (tangential) thing that came up is that tuple element names in tuple 
*patterns* should probably be deprecated and removed at some point.  Without 
looking, what variables does this declare?:

let (a : Int, b : Float) = foo()

?

-Chris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Paul Cantrell via swift-evolution]

What’s the status of this Chris’s double parens idea below? It garnered some 
positive responses, but the discussion seems to have fizzled out. Is there 
something needed to help nudge this along?

What’s the likelihood of getting this fixed before Swift 4 goes live, and the 
great wave of readability regressions hits?

P

> On Jun 4, 2017, at 12:16 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Jun 1, 2017, at 3:06 PM, John McCall via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Jun 1, 2017, at 2:39 PM, Pavol Vaskovic >> > wrote:
>>> 
>>> On Thu, Jun 1, 2017 at 8:52 PM, John McCall via swift-evolution 
>>> > wrote:
>>> 
>>> I understand that there are developers who dislike SE-0110's impact on 
>>> certain kinds of functional programming, but that is a very broad complaint 
>>> that is unlikely to reach consensus or acceptance, especially for Swift 4. 
>>> 
>>> The impact of SE-0110 as currently implemented in Swift 4 leads to 
>>> following migration choice wherever you have a closure that takes tuple 
>>> argument:
>>> * concise but obfuscate code ($0.1, ...)
>>> * readable but verbose code (requiring a ton of boilerplate: intermediate 
>>> argument, expand signature to include return type, desctructure tuple on 
>>> new line using let, add return clause)
>>> 
>>> Maybe I misunderstood you, but I don't think this is marginal issue 
>>> affecting only some "developers that dislike the impact on certain kinds of 
>>> functional programming". 
>> 
>> You're misunderstanding me.  I have explicitly said, several times, that I 
>> agree that the impact on tuple destructuring in closures is a serious 
>> regression.  There have *also* been objections to losing argument-splat 
>> behavior, and while that does negatively affect some functional styles, I 
>> think it would be a mistake to try to address that now.
> 
> I agree with both points: we need to fix the type checker 
> semantics+performance regression, but I also sympathize with the beauty 
> regression for closures.  Here are some the examples Gwendal Roué cited 
> up-thread (just to make the discussion concrete):
> 
> Example 1
> -return columns.index { (column, _) in column.lowercased() == 
> lowercaseName }
> +return columns.index { $0.0.lowercased() == lowercaseName }
> 
> Example 2 :
> -.map { (mappedColumn, baseColumn) -> (Int, String) in
> +.map { (pair) -> (Int, String) in
> +let mappedColumn = pair.key
> +let baseColumn = pair.value
> 
> Example 3 :
> -.map { (table, columns) in 
> "\(table)(\(columns.sorted().joined(separator: ", ")))" } 
> +.map { "\($0.key)(\($0.value.sorted().joined(separator: ", 
> ")))" }
> 
> Example 4 :
> -dictionary.first { (column, value) in column.lowercased() == 
> orderedColumn.lowercased() }
> +dictionary.first { $0.key.lowercased() == 
> orderedColumn.lowercased() }
> 
> 
> 
> 
> One way to split the difference here is to eliminate the splatting behavior, 
> but keep the destructuring (irrefutable pattern matching) behavior as well.  
> In these cases, just require an extra explicit paren for the parameter list.  
> This would change the diff's to:
> 
> Example 1
> -return columns.index { (column, _) in column.lowercased() == 
> lowercaseName }
> +   return columns.index { ((column, _)) in column.lowercased() == 
> lowercaseName }
> 
> Example 2 :
> -.map { (mappedColumn, baseColumn) -> (Int, String) in
> +.map { ((mappedColumn, baseColumn)) -> (Int, String) in
> 
> Example 3 :
> -.map { (table, columns) in 
> "\(table)(\(columns.sorted().joined(separator: ", ")))" } 
> +.map { ((table, columns)) in 
> "\(table)(\(columns.sorted().joined(separator: ", ")))" }   
> 
> Example 4 :
> -dictionary.first { (column, value) in column.lowercased() == 
> orderedColumn.lowercased() }
> +dictionary.first { ((column, value)) in column.lowercased() 
> == orderedColumn.lowercased() }
> 
> 
> What do you think?  Seems like it would solve the type checker problem, 
> uglify the code a lot less, and make the fixit/migration happily trivial.
> 
> -Chris
> 
> 
> 
> ___
> 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

Re: [swift-evolution] Revisiting SE-0110

[Stephen Celis via swift-evolution]

> On Jun 6, 2017, at 8:19 PM, Mark Lacey  wrote:
> 
> Thanks for reminding me. It’s good to call out this case specifically. The 
> underlying reason that this is disallowed for Swift 4 is the same as the 
> underlying reason that a closure immediately passed as an argument (with with 
> mismatching function type) is disallowed for Swift 4 (i.e. the “tuple 
> destructuring” case). It might be possible to relax restrictions to allow one 
> of these without allowing the other.
> 
> Having said that, I find it surprising that your tupleUp function works as it 
> is implicitly converting the function type in a way that I would expect 
> SE-0110 to disallow. My expectation is that it would need to be written like 
> this:
> 
> func tupleUp(_ f: @escaping (A, B) -> C) -> ((A, B)) -> C {
>  return { f($0.0, $0.1) }
> }

Ah yes. I was distracted while writing that reply and didn't finish the 
implementation. That looks right, thanks!

I definitely understand the ambiguity issue but there was something nice about 
being able to think of arguments as tuples. I just wish the disambiguation 
could have operated in the opposite direction.

Stephen
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Mark Lacey via swift-evolution]

> On Jun 6, 2017, at 1:59 PM, Stephen Celis  wrote:
> 
>> On Jun 6, 2017, at 1:43 PM, Mark Lacey via swift-evolution 
>>  wrote:
>> 
>> Unless I am missing something this is an example of tuple destructuring. I’m 
>> looking for examples of other issues.
> 
> The destructuring issue is the most pervasive, but as mentioned it also 
> breaks point-free style:
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170529/036911.html
> 
> Again, less common for most but heavily used by us and folks that use 
> functional patterns and libs like RxSwift, ReactiveCocoa, etc., where a lot 
> of streams/signals of values are composed into new structures.

Thanks for reminding me. It’s good to call out this case specifically. The 
underlying reason that this is disallowed for Swift 4 is the same as the 
underlying reason that a closure immediately passed as an argument (with with 
mismatching function type) is disallowed for Swift 4 (i.e. the “tuple 
destructuring” case). It might be possible to relax restrictions to allow one 
of these without allowing the other.

Having said that, I find it surprising that your tupleUp function works as it 
is implicitly converting the function type in a way that I would expect SE-0110 
to disallow. My expectation is that it would need to be written like this:

func tupleUp(_ f: @escaping (A, B) -> C) -> ((A, B)) -> C {
  return { f($0.0, $0.1) }
}

Mark

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Vladimir.S via swift-evolution]

On 07.06.2017 0:45, Mark Lacey wrote:



On Jun 6, 2017, at 11:45 AM, Vladimir.S  wrote:

On 06.06.2017 20:10, Mark Lacey via swift-evolution wrote:

On Jun 6, 2017, at 8:42 AM, Ray Fix via swift-evolution > 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.


What if compiler in Swift 4 will be smart enough to generate correct *type* of 
provided closure depending of required type of function parameter *only* if 
closure defined inside the function call *and* has no type annotations for its 
arguments?


It might be possible to get something like this working.


I mean, that having
func fooTuple(_ c: ((Int,Int))->Void) {..}
func fooParams(_ c: (Int,Int)->Void) {..}

, when we call
fooTuple {x,y in }
- compiler probably can generate closure of correct type ((Int,Int))->Void from 
this code.

and for
fooParams {x,y in }
- compiler can generate closure of type (Int,Int)->Void

But, I suggest this can be allowed only if there is no types specified for x,y. 
This is to reduce the ambiguity - we can't just declare the closure constant or 
func with syntax {x,y in } as we need types for x,y in this case, i.e.

let closure1 = {(x: Int, y: Int) in ..} // this is definitely (Int,Int)->()
let closure2 = {(x: (Int, Int)) in ..} // this is definitely ((Int,Int))->()

// let closure3 = {x, y in .. } // invalid syntax


It would be source breaking to not allow this to work in the cases where it 
does today. We would have to consider this as a function taking two arguments.



Yes, my fault. Missed that Swift is smart enough even for this:
func foo(_ x: Int, _ y: Int) {}
let c = {x,y in foo(x,y)}  // ok, (Int,Int)->()

Btw, what do you think, is it possible to "just allow" accepting of closure/func with 
list of arguments where closure with one tuple argument is required(in case arguments 
and their types are matched and func/closure has no modifiers like 'inout' etc)?
I.e. accept func/closure of type (Int,Int)->() in *all* places where ((Int,Int))->() 
is required?
I mean, in this case one function type is expected, we provide another function type 
without any explicit conversion, can this be easily implemented in Swift 4 and will 
such rule be foreign for Swift's types system? Or it looks like it is more reasonable 
to provide special syntax/conversion for tuple destructuring for both closures and 
free funcs?


Vladimir.


//fooTuple(closure1) // invalid parameter type
//fooParams(closure2) // invalid parameter type
fooTuple {x,y in } // ok, ((Int,Int))->() closure will be generated
fooParams {x,y in } // ok, (Int,Int)->() closure will be generated

So, closure declared inside a func call without types assigned to closure's 
arguments - could be a very special case, when compiler will generate closure 
of needed type.

As I understand, such solution can dramatically reduce the problems with 
migration developers have. And also this will be Swift3 compatible.


Yes, if something like this could be implemented robustly it would make the 
cases where a closure is immediately passed as an argument to a function call 
work and allow most Swift 3 code to continue working.

Mark




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 

Re: [swift-evolution] Revisiting SE-0110

[Stephen Celis via swift-evolution]

> On Jun 6, 2017, at 1:43 PM, Mark Lacey via swift-evolution 
>  wrote:
> 
> Unless I am missing something this is an example of tuple destructuring. I’m 
> looking for examples of other issues.

The destructuring issue is the most pervasive, but as mentioned it also breaks 
point-free style:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170529/036911.html

Again, less common for most but heavily used by us and folks that use 
functional patterns and libs like RxSwift, ReactiveCocoa, etc., where a lot of 
streams/signals of values are composed into new structures.

Stephen
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Vladimir.S via swift-evolution]

On 06.06.2017 20:10, Mark Lacey via swift-evolution wrote:


On Jun 6, 2017, at 8:42 AM, Ray Fix via swift-evolution > 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.


What if compiler in Swift 4 will be smart enough to generate correct *type* of 
provided closure depending of required type of function parameter *only* if closure 
defined inside the function call *and* has no type annotations for its arguments?


I mean, that having
func fooTuple(_ c: ((Int,Int))->Void) {..}
func fooParams(_ c: (Int,Int)->Void) {..}

, when we call
fooTuple {x,y in }
- compiler probably can generate closure of correct type ((Int,Int))->Void from this 
code.


and for
fooParams {x,y in }
- compiler can generate closure of type (Int,Int)->Void

But, I suggest this can be allowed only if there is no types specified for x,y. This 
is to reduce the ambiguity - we can't just declare the closure constant or func with 
syntax {x,y in } as we need types for x,y in this case, i.e.


let closure1 = {(x: Int, y: Int) in ..} // this is definitely (Int,Int)->()
let closure2 = {(x: (Int, Int)) in ..} // this is definitely ((Int,Int))->()

// let closure3 = {x, y in .. } // invalid syntax

//fooTuple(closure1) // invalid parameter type
//fooParams(closure2) // invalid parameter type
fooTuple {x,y in } // ok, ((Int,Int))->() closure will be generated
fooParams {x,y in } // ok, (Int,Int)->() closure will be generated

So, closure declared inside a func call without types assigned to closure's arguments 
- could be a very special case, when compiler will generate closure of needed type.


As I understand, such solution can dramatically reduce the problems with migration 
developers have. And also this will be Swift3 compatible.




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 
> wrote:



On Tue, Jun 6, 2017 at 7:18 AM Gwendal Roué via swift-evolution 
> wrote:




Le 6 juin 2017 à 15:30, Vladimir.S > 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@swift.org 
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Mark Lacey via swift-evolution]

> On Jun 6, 2017, at 10:33 AM, John Holdsworth  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("""
> 
> 
> \(bookTuples.map {
> (id, author, title, genre, price, chapters) in """
> 
> \(author)
> \(title)
> \(genre)
> \(price)
> 
> \(chapters.map {
> (heading) in """
> \(heading)
> 
> """}.joined(separator:"")
> )
> 
> 
> """}.joined(separator:"")
> )
> """)
> 
> 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 
>> > wrote:
>> 
>>> 
>>> On Jun 6, 2017, at 8:42 AM, Ray Fix via swift-evolution 
>>> > 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 
 > wrote:
 
 
 On Tue, Jun 6, 2017 at 7:18 AM Gwendal Roué via swift-evolution 
 > wrote:
 
> Le 6 juin 2017 à 15:30, Vladimir.S  > 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 

Re: [swift-evolution] Revisiting SE-0110

[John Holdsworth via swift-evolution]

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("""


\(bookTuples.map {
(id, author, title, genre, price, chapters) in """

\(author)
\(title)
\(genre)
\(price)

\(chapters.map {
(heading) in """
\(heading)

"""}.joined(separator:"")
)


"""}.joined(separator:"")
)
""")

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 
>  wrote:
> 
>> 
>> On Jun 6, 2017, at 8:42 AM, Ray Fix via swift-evolution 
>> > 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 
>>> > wrote:
>>> 
>>> 
>>> On Tue, Jun 6, 2017 at 7:18 AM Gwendal Roué via swift-evolution 
>>> > wrote:
>>> 
 Le 6 juin 2017 à 15:30, Vladimir.S > 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@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
> 
> 

Re: [swift-evolution] Revisiting SE-0110

[Mark Lacey via swift-evolution]

> On Jun 6, 2017, at 8:42 AM, Ray Fix via swift-evolution 
>  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 
>> > wrote:
>> 
>> 
>> On Tue, Jun 6, 2017 at 7:18 AM Gwendal Roué via swift-evolution 
>> > wrote:
>> 
>>> Le 6 juin 2017 à 15:30, Vladimir.S >> > 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@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

Re: [swift-evolution] Revisiting SE-0110

[Ray Fix via swift-evolution]

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.

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 
>  wrote:
> 
> 
> On Tue, Jun 6, 2017 at 7:18 AM Gwendal Roué via swift-evolution 
> > wrote:
> 
>> Le 6 juin 2017 à 15:30, Vladimir.S > > 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@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

Re: [swift-evolution] Revisiting SE-0110

[Gwendal Roué via swift-evolution]

> Le 6 juin 2017 à 17:22, Shawn Erickson  a écrit :
> 
> 
> On Tue, Jun 6, 2017 at 7:18 AM Gwendal Roué via swift-evolution 
> > wrote:
> 
>> Le 6 juin 2017 à 15:30, Vladimir.S > > 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

You are right, Shawn. I hope that the core team is currently enjoying all the 
congratulations they deserve :-)

Gwendal

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Vladimir.S via swift-evolution]

On 06.06.2017 16:53, Víctor Pimentel Rodríguez wrote:
On Tue, Jun 6, 2017 at 3:30 PM, Vladimir.S via swift-evolution 
> wrote:


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)->())  // ??


Vladimir.


I think most developers would not care about or notice that discrepancy, while most 
will encounter the regression in closures and specially in the Dictionary API. In 
fact most developers will have this reaction:


https://owensd.io/2017/06/01/se-110-fallout-im-confused/

Please, I don't mean that the type discrepancy should not be changed or that the 
proposals have not value, it's just a matter of priorities here.


SE-0066 and SE-0110 was reviewed and accepted to be implemented for *Swift 3*, but 
due to some reasons they were not (fully) implemented and were delayed for Swift 4. 
SE-0110 was not just brought the last minute before release for Swift 4. So I 
personally don't understand about which 'priorities' you thinking about.


Also please note that after Swift 4 is released, it seems like we will not be able to 
fix the function types for long time because of source compatibility rules.


And I just want again point out, as I understand, that function type inconsistency 
*should* be fixed by *SE-0066*, not SE-0110. SE-0110 just follows the way.


All I'm trying to find out(from core team, actually) *what will be the result of this 
code in Swif4 Release due to requirements of SE-0066(!)* :


func foo(x : (Int, Int))->() {}

print( type(of: foo) )  // ??
print( foo is (_: Int, _: Int)->() )  // ??
print( ( (_: Int, _: Int)->() ).self == ( ((Int,Int))->() ).self ) // ??

As I understand, *this* is the main point actually. Please follow my reasoning:

* If type(of: foo) will be still(as currently) (Int,Int)->() , then I have a question 
if SE-0066 actually be *fully* implemented in Swift 4 *or* core team decided to 
revisit SE-0066 or decided to implement it only partially.
  If they decided to revert SE-0066 or implement partially, then I don't understand 
the whole point of introduced complexity for function types, why we need separate 
type for function with single tuple if it is not reflected in type system. And *in 
this case* I also don't see any sense in SE-0110 because IMO type system for function 
types will still be broken.


* But, if type(of: foo) will be ((Int,Int))->() as expected, then we have this 
situation: some function can require a parameter of function type ((Int,Int))->() and 
we want to provide (Int,Int)->() to it.  So, we have to answer to these questions:


  1. What is the type of {(x: Int, y: Int) in } and {(x: (Int,Int)) in } closures ? 
I expect they must be (Int,Int)->() and ((Int,Int))->() accordingly.


  2. What is the type of {x,y in } if it is defined inside func call where argument 
of type ((Int,Int))->() is expected ? If {x,y in} can be treated as different type 
depends on context, can {(x,y) in } also ? can {(x: Int, y: Int) in} also?


  3. Can we just send instance of type (Int,Int)->() when ((Int,Int))->() is 
required, i.e. will we allow implicit conversion between such specific function types 
in all contexts?


  4. If we are not going to allow implicit conversion, what syntax we introduce to 
destructure tuple argument in closure or just disallow calling the function with 
wrong closure type(the latter was accepted as SE-0110).


Note, that if  type(of: foo) will be '((Int,Int))->()' in Swift 4 - we just have no 
option to 'just' drop SE-0110 without answering the above questions, because we have 
a situation when parameter(closure) of wrong type is provided.


Of course, I support any solution that allows compact code to destructure tuple 
argument in closure, but with strong respect of correct function types in Swift 4.


Actually I do feel like I'm missing something important about function types in Swift 
4, SE-0066 and SE-0110 and continue to fight with a wind, so I'll be glad  someone 
points me to correct direction :-)


Vladimir.



--
Víctor Pimentel

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Shawn Erickson via swift-evolution]

On Tue, Jun 6, 2017 at 7:18 AM Gwendal Roué via swift-evolution <
swift-evolution@swift.org> wrote:

>
> Le 6 juin 2017 à 15:30, Vladimir.S  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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Víctor Pimentel Rodríguez via swift-evolution]

On Tue, Jun 6, 2017 at 3:30 PM, Vladimir.S via swift-evolution <
swift-evolution@swift.org> wrote:

> 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)->())  // ??
>
>
> Vladimir.
>

I think most developers would not care about or notice that discrepancy,
while most will encounter the regression in closures and specially in the
Dictionary API. In fact most developers will have this reaction:

https://owensd.io/2017/06/01/se-110-fallout-im-confused/

Please, I don't mean that the type discrepancy should not be changed or
that the proposals have not value, it's just a matter of priorities here.

-- 
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Gwendal Roué via swift-evolution]

> Le 6 juin 2017 à 15:30, Vladimir.S  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).

Gwendal

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Vladimir.S via swift-evolution]

On 06.06.2017 15:32, Gwendal Roué wrote:


Le 6 juin 2017 à 12:06, Vladimir.S > a 
écrit :


On 06.06.2017 7:36, Gwendal Roué wrote:

http://adcdownload.apple.com/WWDC_2017/Xcode_9_beta/Xcode_9_beta_Release_Notes.pdf
The migrator does not properly distinquish between single-tuple and 
multiple-argument function types as described in SE–0110, causing additional 
mismatched type errors with the closure types that are passed to Standard Library 
functions expecting tuple objects. (32431899)


Workaround: Manually fix the closure types to accept values of tuples instead of 
separate argument values.



When using $0 and $1 in a closure that is passed to a function expecting a 
closure with a single tuple argument, the compiler may error after migration with:


error: closure tuple parameter '(TYPE, TYPE)' does not support destructuring with 
implicit parameters


(32489893)

Workaround: Change $0 and $1 references to $0.0 and $0.1 respectively.


Where are the firemen?


Could you help me to understand which of my question did you reply on with the 
above link and quotes? What are you trying to say? Thank you.


Oh, just that the Xcode 9 beta release notes list not less than four (four!) known 
issues related to SE-0110.


On top of the already discussed regressions introduced by SE-0110, we now have a 
painful migration.


I wonder why we're still spilling blood, why the fire hasn't been extinguish yet. 
Hence: where are the firemen?




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)->())  // ??


Vladimir.

Is there anybody responsible here? When will this endless discussion about 
"revisiting SE-0110" will eventually end with a reasonable decision?


When will the proposal process will be amended so that developers should be given a 
voice, along with language layers, on swift evolution? Developers don't have the same 
skills as language layers. Too many developers lack the poise and confidence to talk 
about the future impact of a language modification. Too many language layers fail to 
admit that some language modification do actual harm on written code after they have 
invested a lot of time thinking about it. That's normal.


And that's a recipe for things like SE-0110.

What I've read here so far makes me think SE-0110 belongs to the "false good ideas", 
as SE-0025 have been before. Along with SE-0025, maybe SE-0166, it has been deemed 
"stable" much too early. Unfortunately, the swift evolution process only produces 
stable amendments that are very painful to fix. I wish the core team would think 
about it some day: aren't the quality of the language and its core libraries at stake?


Gwendal


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Gwendal Roué via swift-evolution]

> Le 6 juin 2017 à 12:06, Vladimir.S  a écrit :
> 
> On 06.06.2017 7:36, Gwendal Roué wrote:
>> http://adcdownload.apple.com/WWDC_2017/Xcode_9_beta/Xcode_9_beta_Release_Notes.pdf
>>> The migrator does not properly distinquish between single-tuple and 
>>> multiple-argument function types as described in SE–0110, causing 
>>> additional mismatched type errors with the closure types that are passed to 
>>> Standard Library functions expecting tuple objects. (32431899)
>>> 
>>> Workaround: Manually fix the closure types to accept values of tuples 
>>> instead of separate argument values.
>>> 
>>> 
>>> When using $0 and $1 in a closure that is passed to a function expecting a 
>>> closure with a single tuple argument, the compiler may error after 
>>> migration with:
>>> 
>>> error: closure tuple parameter '(TYPE, TYPE)' does not support 
>>> destructuring with implicit parameters
>>> 
>>> (32489893)
>>> 
>>> Workaround: Change $0 and $1 references to $0.0 and $0.1 respectively.
>>> 
>> Where are the firemen?
> 
> Could you help me to understand which of my question did you reply on with 
> the above link and quotes? What are you trying to say? Thank you.

Oh, just that the Xcode 9 beta release notes list not less than four (four!) 
known issues related to SE-0110.

On top of the already discussed regressions introduced by SE-0110, we now have 
a painful migration.

I wonder why we're still spilling blood, why the fire hasn't been extinguish 
yet. Hence: where are the firemen?

Is there anybody responsible here? When will this endless discussion about 
"revisiting SE-0110" will eventually end with a reasonable decision?

When will the proposal process will be amended so that developers should be 
given a voice, along with language layers, on swift evolution? Developers don't 
have the same skills as language layers. Too many developers lack the poise and 
confidence to talk about the future impact of a language modification. Too many 
language layers fail to admit that some language modification do actual harm on 
written code after they have invested a lot of time thinking about it. That's 
normal.

And that's a recipe for things like SE-0110.

What I've read here so far makes me think SE-0110 belongs to the "false good 
ideas", as SE-0025 have been before. Along with SE-0025, maybe SE-0166, it has 
been deemed "stable" much too early. Unfortunately, the swift evolution process 
only produces stable amendments that are very painful to fix. I wish the core 
team would think about it some day: aren't the quality of the language and its 
core libraries at stake?

Gwendal

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Vladimir.S via swift-evolution]

On 06.06.2017 7:36, Gwendal Roué wrote:

http://adcdownload.apple.com/WWDC_2017/Xcode_9_beta/Xcode_9_beta_Release_Notes.pdf

The migrator does not properly distinquish between single-tuple and 
multiple-argument function types as described in SE–0110, causing additional 
mismatched type errors with the closure types that are passed to Standard Library 
functions expecting tuple objects. (32431899)


Workaround: Manually fix the closure types to accept values of tuples instead of 
separate argument values.



When using $0 and $1 in a closure that is passed to a function expecting a closure 
with a single tuple argument, the compiler may error after migration with:


error: closure tuple parameter '(TYPE, TYPE)' does not support destructuring with 
implicit parameters


(32489893)

Workaround: Change $0 and $1 references to $0.0 and $0.1 respectively.


Where are the firemen?


Could you help me to understand which of my question did you reply on with the above 
link and quotes? What are you trying to say? Thank you.




Gwendal


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Gwendal Roué via swift-evolution]

Wait, there's more!
> When passing a closure with a single underscore argument ({ _ in ...}) to a 
> function expecting multiple arguments, the compiler may error after migration 
> with:
> 
> error: cannot convert value of type '(_) -> ()' to expected argument
> type
> (32301091)
> Workaround: To fix the error, change the single argument to the correct 
> number of arguments
> 
> such as { (_,_) in ...}
> 
> 
> 
> When passing a closure to map with two function arguments, the compiler may 
> after migration error with:
> 
>error: 'map' produces '[T]', not the expected contextual result type
>''
> (32432752)
> Workaround: Change the closure signature to accept a tuple argument of two 
> elements when
> 
> using map. 
> 

Gwendal

> Le 6 juin 2017 à 06:36, Gwendal Roué  a écrit :
> 
> http://adcdownload.apple.com/WWDC_2017/Xcode_9_beta/Xcode_9_beta_Release_Notes.pdf
>  
> 
> 
>> The migrator does not properly distinquish between single-tuple and 
>> multiple-argument function types as described in SE–0110, causing additional 
>> mismatched type errors with the closure types that are passed to Standard 
>> Library functions expecting tuple objects. (32431899)
>> 
>> Workaround: Manually fix the closure types to accept values of tuples 
>> instead of separate argument values.
>> 
>> 
>> 
>> When using $0 and $1 in a closure that is passed to a function expecting a 
>> closure with a single tuple argument, the compiler may error after migration 
>> with:
>> 
>> error: closure tuple parameter '(TYPE, TYPE)' does not support
>> destructuring with implicit parameters
>> (32489893)
>> 
>> Workaround: Change $0 and $1 references to $0.0 and $0.1 respectively. 
>> 
> Where are the firemen?
> 
> Gwendal
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Gwendal Roué via swift-evolution]

http://adcdownload.apple.com/WWDC_2017/Xcode_9_beta/Xcode_9_beta_Release_Notes.pdf

> The migrator does not properly distinquish between single-tuple and 
> multiple-argument function types as described in SE–0110, causing additional 
> mismatched type errors with the closure types that are passed to Standard 
> Library functions expecting tuple objects. (32431899)
> 
> Workaround: Manually fix the closure types to accept values of tuples instead 
> of separate argument values.
> 
> 
> 
> When using $0 and $1 in a closure that is passed to a function expecting a 
> closure with a single tuple argument, the compiler may error after migration 
> with:
> 
> error: closure tuple parameter '(TYPE, TYPE)' does not support
> destructuring with implicit parameters
> (32489893)
> 
> Workaround: Change $0 and $1 references to $0.0 and $0.1 respectively. 
> 
Where are the firemen?

Gwendal

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Vladimir.S via swift-evolution]

Yes, double parenthesis for tuple argument destructuring in closure was discussed in 
this thread, and I feel it is one of the best options.


But the main question I can't find the clear answer for, what will be with 
function/closure types in Swift 4. IMO *this* is the main question, not the syntax 
for tuple destructuring.


Chris, could you please help to clarify the situation with SE-0066 and SE-0110?
In Rationale part of the SE-0110 acceptance message you said:
"... The community and core team agree that this proposal is the right thing to do, 
and many agree that this could probably have been treated as a bug fix on a previous 
proposal.

..."
(https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000215.html)

Were you thinking about SE-0110 just as bug fix for SE-0066/SE-0029?

What is your opinion, can we revisit SE-0110 without revisiting SE-0066?

I mean that for me SE-0066 clearly separated *types* for function with one tuple 
argument and a list of arguments, so (Int,Int)->Void is not the same *type* as 
((Int,Int))->Void, and so we just must to assign a right concrete type for 
closure(depending on its arguments), so we must separate closures that takes one 
tuple argument and a list of arguments. And SE-0110 just clarifies this.


How do you think, what should be a *type* of these constants after SE-0066?:

let closure1 = {(x: Int, y: Int) in}
let closure2 = {(x: (Int,Int)) in }

print(type(of: closure1)) // ?
print(type(of: closure2)) // ?

For me, based on *SE-0066*, they must be typed as (Int, Int)->Void and 
((Int,Int))->Void accordingly, no?


Should type(of: closure1) == type(of: closure2) ?
Can (closure2 is (Int,Int)->Void) == true ?
and (closure1 is ((Int,Int))->Void) == true ?

Having function
func foo(callback: (_ x:(Int,Int))->Void) {..}

, should we be able to just send closure1 to it? I.e.
foo(callback: closure1)  // ?
foo(callback:  {(x: Int, y: Int) in}) // and here?
foo(callback: {x, y in }) // and here?

I even think that we can have implicit conversion between these *types* of 
closures/funcs (one tuple vs arg list), because this seems to be very handy and used 
a lot, but IMO after SE-0066 we should have clear and strict type for each kind of 
func/closure and then, can have clear rule that we can use one *type*, where *another 
type* is required.
Or allow just tuple destructuring by *special* syntax in closure. Again, closure will 
be of correct *type* but contains tuple destructuring syntax.
Or disallow using of different *type* of func/closure when another type is 
requested.(Exactly this was proposed and accepted by SE-0110, that was inspired by 
SE-0066)


Having all these said, I can't understand how we can actually revisit SE-0110, 
because it just clarifies for closures what SE-0066 requires for function types.


Thank you.
Vladimir.

On 04.06.2017 20:16, Chris Lattner via swift-evolution wrote:


On Jun 1, 2017, at 3:06 PM, John McCall via swift-evolution 
> wrote:




On Jun 1, 2017, at 2:39 PM, Pavol Vaskovic > 
wrote:

On Thu, Jun 1, 2017 at 8:52 PM, John McCall via swift-evolution 
> wrote:



I understand that there are developers who dislike SE-0110's impact on 
certain
kinds of functional programming, but that is a very broad complaint that is
unlikely to reach consensus or acceptance, especially for Swift 4. 



The impact of SE-0110 as currently implemented in Swift 4 leads to following 
migration choice wherever you have a closure that takes tuple argument:

* concise but obfuscate code ($0.1, ...)
* readable but verbose code (requiring a ton of boilerplate: intermediate 
argument, expand signature to include return type, desctructure tuple on new line 
using let, add return clause)


Maybe I misunderstood you, but I don't think this is marginal issue affecting only 
some "developers that dislike the impact on certain kinds of functional programming". 


You're misunderstanding me.  I have explicitly said, several times, that I agree 
that the impact on tuple destructuring in closures is a serious regression.  There 
have *also* been objections to losing argument-splat behavior, and while that does 
negatively affect some functional styles, I think it would be a mistake to try to 
address that now.


I agree with both points: we need to fix the type checker semantics+performance 
regression, but I also sympathize with the beauty regression for closures.  Here are 
some the examples Gwendal Roué cited up-thread (just to make the discussion concrete):


Example 1
-return columns.index { (column, _) in column.lowercased() == 
lowercaseName }
+return columns.index { $0.0.lowercased() == lowercaseName }

Example 2 :
-.map { (mappedColumn, baseColumn) -> (Int, String) in
+.map { (pair) -> (Int, String) in
+let mappedColumn 

Re: [swift-evolution] Revisiting SE-0110

[Víctor Pimentel Rodríguez via swift-evolution]

On Mon, Jun 5, 2017 at 9:31 AM, Gwendal Roué via swift-evolution <
swift-evolution@swift.org> wrote:

> The motivation section is not at all about any "type checker problem".
> It's about a postulate that has been proven horribly source-breaking, and
> counter-productive. The type safety argument is moot. The principle of
> least surprise has been blown away by SE-0110, putting Swift aside from the
> majority of other languages.
>
> I'm surprised that everybody tries to workaround SE-0110 consequences,
> admitting that it's relevant, instead of revisiting SE-0110 at its very
> root.
>
> Gwendal
>

+1 to this.

In practice, we have seen that the previous behaviour was incredibly
versatile and it allowed for more expressive code; using tuples in generic
types is much more pleasant to use (eg: Dictionary and similar
collections). I suppose most users of that Dictionary API did not know that
those blocks were accepting tuples and not several parameters, but still
they were productive with those APIs. Now we will require them to know what
I consider is a implementation detail, which adds a small cognitive load
when they try to use them.

So, which syntax is considered to be better? To me, every proposed syntax
is worse than the previous one, even more considering that this will be a
breaking change. And we do not need to invent some examples, we have real
usages that we can reason about:

https://github.com/Alamofire/Alamofire/blob/c8700ac7ea6b7efa7200e2920bf528e88b4dbee6/Source/ParameterEncoding.swift#L245

return components.map { "\($0)=\($1)" }.joined(separator: "&")

I suppose that with Swift 4 that line of code will be rewritten as this:

return components.map { "\($0.0)=\($0.1)" }.joined(separator: "&")

No matter the workaround, that will be the case. That is not Swift code I
want to write nor maintain.

Can't we delay the release of SE-0110 until Swift 5, where we can reason
more about its consequences? Are the gains in compilation times so
impressive? Do we want to hinder such code patterns because of "type
safety"? Are there any real world examples where that has been an issue?

Thanks,

-- 
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Gwendal Roué via swift-evolution]

> Le 4 juin 2017 à 19:16, Chris Lattner via swift-evolution 
>  a écrit :
> 
> One way to split the difference here is to eliminate the splatting behavior, 
> but keep the destructuring (irrefutable pattern matching) behavior as well.  
> In these cases, just require an extra explicit paren for the parameter list.  
> This would change the diff's to:
> 
> Example 1
> -return columns.index { (column, _) in column.lowercased() == 
> lowercaseName }
> +   return columns.index { ((column, _)) in column.lowercased() == 
> lowercaseName }
> 
> Example 2 :
> -.map { (mappedColumn, baseColumn) -> (Int, String) in
> +.map { ((mappedColumn, baseColumn)) -> (Int, String) in
> 
> Example 3 :
> -.map { (table, columns) in 
> "\(table)(\(columns.sorted().joined(separator: ", ")))" } 
> +.map { ((table, columns)) in 
> "\(table)(\(columns.sorted().joined(separator: ", ")))" }   
> 
> Example 4 :
> -dictionary.first { (column, value) in column.lowercased() == 
> orderedColumn.lowercased() }
> +dictionary.first { ((column, value)) in column.lowercased() 
> == orderedColumn.lowercased() }
> 
> 
> What do you think?  Seems like it would solve the type checker problem, 
> uglify the code a lot less, and make the fixit/migration happily trivial.
> 
> -Chris

Thanks for your feedback !

Your solution performs much better, but only to some point: the developers will 
just add parenthesis until the compiler is happy.

Quoting 
https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md:
 


> ## Motivation
> 
> Right now, the following is possible:
> 
> let fn1 : (Int, Int) -> Void = { x in 
> // The type of x is the tuple (Int, Int).
> // ...
> }
> 
> 
> let fn2 : (Int, Int) -> Void = { x, y in
> // The type of x is Int, the type of y is Int.
> // ...
> }
> 
> A variable of function type where there exist n parameters (where n > 1) can 
> be assigned a value (whether it be a named function, a closure literal, or 
> other acceptable value) which either takes in n parameters, or one tuple 
> containing n elements. This seems to be an artifact of the tuple splat 
> behavior removed in SE-0029.
> 
> The current behavior violates the principle of least surprise and weakens 
> type safety, and should be changed.

The motivation section is not at all about any "type checker problem". It's 
about a postulate that has been proven horribly source-breaking, and 
counter-productive. The type safety argument is moot. The principle of least 
surprise has been blown away by SE-0110, putting Swift aside from the majority 
of other languages.

I'm surprised that everybody tries to workaround SE-0110 consequences, 
admitting that it's relevant, instead of revisiting SE-0110 at its very root.

Gwendal

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[rintaro ishizaki via swift-evolution]

2017-06-05 2:16 GMT+09:00 Chris Lattner via swift-evolution <
swift-evolution@swift.org>:

>
> On Jun 1, 2017, at 3:06 PM, John McCall via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Jun 1, 2017, at 2:39 PM, Pavol Vaskovic  wrote:
>
> On Thu, Jun 1, 2017 at 8:52 PM, John McCall via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> I understand that there are developers who dislike SE-0110's impact on
>> certain kinds of functional programming, but that is a very broad complaint
>> that is unlikely to reach consensus or acceptance, especially for Swift 4.
>
>
> The impact of SE-0110 as currently implemented in Swift 4 leads to
> following migration choice wherever you have a closure that takes tuple
> argument:
> * concise but obfuscate code ($0.1, ...)
> * readable but verbose code (requiring a ton of boilerplate: intermediate
> argument, expand signature to include return type, desctructure tuple on
> new line using let, add return clause)
>
> Maybe I misunderstood you, but I don't think this is marginal issue
> affecting only some "developers that dislike the impact on certain kinds of
> functional programming".
>
>
> You're misunderstanding me.  I have explicitly said, several times, that I
> agree that the impact on tuple destructuring in closures is a serious
> regression.  There have *also* been objections to losing argument-splat
> behavior, and while that does negatively affect some functional styles, I
> think it would be a mistake to try to address that now.
>
>
> I agree with both points: we need to fix the type checker
> semantics+performance regression, but I also sympathize with the beauty
> regression for closures.  Here are some the examples Gwendal Roué cited
> up-thread (just to make the discussion concrete):
>
> Example 1
> -return columns.index { (column, _) in column.lowercased() ==
> lowercaseName }
> +return columns.index { $0.0.lowercased() == lowercaseName }
>
> Example 2 :
> -.map { (mappedColumn, baseColumn) -> (Int, String) in
> +.map { (pair) -> (Int, String) in
> +let mappedColumn = pair.key
> +let baseColumn = pair.value
>
> Example 3 :
> -.map { (table, columns) in 
> "\(table)(\(columns.sorted().joined(separator:
> ", ")))" }
> +.map { "\($0.key)(\($0.value.sorted().joined(separator:
> ", ")))" }
>
> Example 4 :
> -dictionary.first { (column, value) in
> column.lowercased() == orderedColumn.lowercased() }
> +dictionary.first { $0.key.lowercased() ==
> orderedColumn.lowercased() }
>
>
>
>
> One way to split the difference here is to eliminate the splatting
> behavior, but keep the destructuring (irrefutable pattern matching)
> behavior as well.  In these cases, just require an extra explicit paren for
> the parameter list.  This would change the diff's to:
>
> Example 1
> -return columns.index { (column, _) in column.lowercased() ==
> lowercaseName }
> +   return columns.index { ((column, _)) in column.lowercased() ==
> lowercaseName }
>
> Example 2 :
> -.map { (mappedColumn, baseColumn) -> (Int, String) in
> +.map { ((mappedColumn, baseColumn)) -> (Int, String) in
>
> Example 3 :
> -.map { (table, columns) in 
> "\(table)(\(columns.sorted().joined(separator:
> ", ")))" }
> +.map { ((table, columns)) in 
> "\(table)(\(columns.sorted().joined(separator:
> ", ")))" }
>
> Example 4 :
> -dictionary.first { (column, value) in
> column.lowercased() == orderedColumn.lowercased() }
> +dictionary.first { ((column, value)) in
> column.lowercased() == orderedColumn.lowercased() }
>
>
> What do you think?  Seems like it would solve the type checker problem,
> uglify the code a lot less, and make the fixit/migration happily trivial.
>
>
+1.

Migration path would be a little less simple if the parameter clause has
type annotations:

-let fn: Int = { (v: String, k: Int) in
+let fn: Int = { ((v, k): (String, Int)) in

Also, if we accept patterns for closure parameters, we probably don't want
to accept '...' for them.

let fn = { ((_, v): (Int, String)...) -> Int in



> -Chris
>
>
>
>
> ___
> 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

Re: [swift-evolution] Revisiting SE-0110

[Paul Cantrell via swift-evolution]

> One way to split the difference here is to eliminate the splatting behavior, 
> but keep the destructuring (irrefutable pattern matching) behavior as well.

A hearty +1 to this, regardless of the choice of syntax.

P

> On Jun 4, 2017, at 12:16 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Jun 1, 2017, at 3:06 PM, John McCall via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Jun 1, 2017, at 2:39 PM, Pavol Vaskovic >> > wrote:
>>> 
>>> On Thu, Jun 1, 2017 at 8:52 PM, John McCall via swift-evolution 
>>> > wrote:
>>> 
>>> I understand that there are developers who dislike SE-0110's impact on 
>>> certain kinds of functional programming, but that is a very broad complaint 
>>> that is unlikely to reach consensus or acceptance, especially for Swift 4. 
>>> 
>>> The impact of SE-0110 as currently implemented in Swift 4 leads to 
>>> following migration choice wherever you have a closure that takes tuple 
>>> argument:
>>> * concise but obfuscate code ($0.1, ...)
>>> * readable but verbose code (requiring a ton of boilerplate: intermediate 
>>> argument, expand signature to include return type, desctructure tuple on 
>>> new line using let, add return clause)
>>> 
>>> Maybe I misunderstood you, but I don't think this is marginal issue 
>>> affecting only some "developers that dislike the impact on certain kinds of 
>>> functional programming". 
>> 
>> You're misunderstanding me.  I have explicitly said, several times, that I 
>> agree that the impact on tuple destructuring in closures is a serious 
>> regression.  There have *also* been objections to losing argument-splat 
>> behavior, and while that does negatively affect some functional styles, I 
>> think it would be a mistake to try to address that now.
> 
> I agree with both points: we need to fix the type checker 
> semantics+performance regression, but I also sympathize with the beauty 
> regression for closures.  Here are some the examples Gwendal Roué cited 
> up-thread (just to make the discussion concrete):
> 
> Example 1
> -return columns.index { (column, _) in column.lowercased() == 
> lowercaseName }
> +return columns.index { $0.0.lowercased() == lowercaseName }
> 
> Example 2 :
> -.map { (mappedColumn, baseColumn) -> (Int, String) in
> +.map { (pair) -> (Int, String) in
> +let mappedColumn = pair.key
> +let baseColumn = pair.value
> 
> Example 3 :
> -.map { (table, columns) in 
> "\(table)(\(columns.sorted().joined(separator: ", ")))" } 
> +.map { "\($0.key)(\($0.value.sorted().joined(separator: ", 
> ")))" }
> 
> Example 4 :
> -dictionary.first { (column, value) in column.lowercased() == 
> orderedColumn.lowercased() }
> +dictionary.first { $0.key.lowercased() == 
> orderedColumn.lowercased() }
> 
> 
> 
> 
> One way to split the difference here is to eliminate the splatting behavior, 
> but keep the destructuring (irrefutable pattern matching) behavior as well.  
> In these cases, just require an extra explicit paren for the parameter list.  
> This would change the diff's to:
> 
> Example 1
> -return columns.index { (column, _) in column.lowercased() == 
> lowercaseName }
> +   return columns.index { ((column, _)) in column.lowercased() == 
> lowercaseName }
> 
> Example 2 :
> -.map { (mappedColumn, baseColumn) -> (Int, String) in
> +.map { ((mappedColumn, baseColumn)) -> (Int, String) in
> 
> Example 3 :
> -.map { (table, columns) in 
> "\(table)(\(columns.sorted().joined(separator: ", ")))" } 
> +.map { ((table, columns)) in 
> "\(table)(\(columns.sorted().joined(separator: ", ")))" }   
> 
> Example 4 :
> -dictionary.first { (column, value) in column.lowercased() == 
> orderedColumn.lowercased() }
> +dictionary.first { ((column, value)) in column.lowercased() 
> == orderedColumn.lowercased() }
> 
> 
> What do you think?  Seems like it would solve the type checker problem, 
> uglify the code a lot less, and make the fixit/migration happily trivial.
> 
> -Chris
> 
> 
> 
> ___
> 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

Re: [swift-evolution] Revisiting SE-0110

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jun 4, 2017, at 12:16 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>>> On Jun 1, 2017, at 3:06 PM, John McCall via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> On Jun 1, 2017, at 2:39 PM, Pavol Vaskovic  wrote:
>>> 
 On Thu, Jun 1, 2017 at 8:52 PM, John McCall via swift-evolution 
  wrote:
 
 I understand that there are developers who dislike SE-0110's impact on 
 certain kinds of functional programming, but that is a very broad 
 complaint that is unlikely to reach consensus or acceptance, especially 
 for Swift 4. 
>>> 
>>> The impact of SE-0110 as currently implemented in Swift 4 leads to 
>>> following migration choice wherever you have a closure that takes tuple 
>>> argument:
>>> * concise but obfuscate code ($0.1, ...)
>>> * readable but verbose code (requiring a ton of boilerplate: intermediate 
>>> argument, expand signature to include return type, desctructure tuple on 
>>> new line using let, add return clause)
>>> 
>>> Maybe I misunderstood you, but I don't think this is marginal issue 
>>> affecting only some "developers that dislike the impact on certain kinds of 
>>> functional programming". 
>> 
>> You're misunderstanding me.  I have explicitly said, several times, that I 
>> agree that the impact on tuple destructuring in closures is a serious 
>> regression.  There have *also* been objections to losing argument-splat 
>> behavior, and while that does negatively affect some functional styles, I 
>> think it would be a mistake to try to address that now.
> 
> I agree with both points: we need to fix the type checker 
> semantics+performance regression, but I also sympathize with the beauty 
> regression for closures.  Here are some the examples Gwendal Roué cited 
> up-thread (just to make the discussion concrete):
> 
> Example 1
> -return columns.index { (column, _) in column.lowercased() == 
> lowercaseName }
> +return columns.index { $0.0.lowercased() == lowercaseName }
> 
> Example 2 :
> -.map { (mappedColumn, baseColumn) -> (Int, String) in
> +.map { (pair) -> (Int, String) in
> +let mappedColumn = pair.key
> +let baseColumn = pair.value
> 
> Example 3 :
> -.map { (table, columns) in 
> "\(table)(\(columns.sorted().joined(separator: ", ")))" } 
> +.map { "\($0.key)(\($0.value.sorted().joined(separator: ", 
> ")))" }
> 
> Example 4 :
> -dictionary.first { (column, value) in column.lowercased() == 
> orderedColumn.lowercased() }
> +dictionary.first { $0.key.lowercased() == 
> orderedColumn.lowercased() }
> 
> 
> 
> 
> One way to split the difference here is to eliminate the splatting behavior, 
> but keep the destructuring (irrefutable pattern matching) behavior as well.  
> In these cases, just require an extra explicit paren for the parameter list.  
> This would change the diff's to:
> 
> Example 1
> -return columns.index { (column, _) in column.lowercased() == 
> lowercaseName }
> +   return columns.index { ((column, _)) in column.lowercased() == 
> lowercaseName }
> 
> Example 2 :
> -.map { (mappedColumn, baseColumn) -> (Int, String) in
> +.map { ((mappedColumn, baseColumn)) -> (Int, String) in
> 
> Example 3 :
> -.map { (table, columns) in 
> "\(table)(\(columns.sorted().joined(separator: ", ")))" } 
> +.map { ((table, columns)) in 
> "\(table)(\(columns.sorted().joined(separator: ", ")))" }   
> 
> Example 4 :
> -dictionary.first { (column, value) in column.lowercased() == 
> orderedColumn.lowercased() }
> +dictionary.first { ((column, value)) in column.lowercased() 
> == orderedColumn.lowercased() }
> 
> 
> What do you think?  Seems like it would solve the type checker problem, 
> uglify the code a lot less, and make the fixit/migration happily trivial.

I've been quietly following the thread.  This approach makes sense to me.
> 
> -Chris
> 
> 
> 
> ___
> 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

Re: [swift-evolution] Revisiting SE-0110

[Chris Lattner via swift-evolution]

> On Jun 1, 2017, at 3:06 PM, John McCall via swift-evolution 
>  wrote:
> 
> 
>> On Jun 1, 2017, at 2:39 PM, Pavol Vaskovic > > wrote:
>> 
>> On Thu, Jun 1, 2017 at 8:52 PM, John McCall via swift-evolution 
>> > wrote:
>> 
>> I understand that there are developers who dislike SE-0110's impact on 
>> certain kinds of functional programming, but that is a very broad complaint 
>> that is unlikely to reach consensus or acceptance, especially for Swift 4. 
>> 
>> The impact of SE-0110 as currently implemented in Swift 4 leads to following 
>> migration choice wherever you have a closure that takes tuple argument:
>> * concise but obfuscate code ($0.1, ...)
>> * readable but verbose code (requiring a ton of boilerplate: intermediate 
>> argument, expand signature to include return type, desctructure tuple on new 
>> line using let, add return clause)
>> 
>> Maybe I misunderstood you, but I don't think this is marginal issue 
>> affecting only some "developers that dislike the impact on certain kinds of 
>> functional programming". 
> 
> You're misunderstanding me.  I have explicitly said, several times, that I 
> agree that the impact on tuple destructuring in closures is a serious 
> regression.  There have *also* been objections to losing argument-splat 
> behavior, and while that does negatively affect some functional styles, I 
> think it would be a mistake to try to address that now.

I agree with both points: we need to fix the type checker semantics+performance 
regression, but I also sympathize with the beauty regression for closures.  
Here are some the examples Gwendal Roué cited up-thread (just to make the 
discussion concrete):

Example 1
-return columns.index { (column, _) in column.lowercased() == 
lowercaseName }
+return columns.index { $0.0.lowercased() == lowercaseName }

Example 2 :
-.map { (mappedColumn, baseColumn) -> (Int, String) in
+.map { (pair) -> (Int, String) in
+let mappedColumn = pair.key
+let baseColumn = pair.value

Example 3 :
-.map { (table, columns) in 
"\(table)(\(columns.sorted().joined(separator: ", ")))" }   
+.map { "\($0.key)(\($0.value.sorted().joined(separator: ", 
")))" }

Example 4 :
-dictionary.first { (column, value) in column.lowercased() == 
orderedColumn.lowercased() }
+dictionary.first { $0.key.lowercased() == 
orderedColumn.lowercased() }




One way to split the difference here is to eliminate the splatting behavior, 
but keep the destructuring (irrefutable pattern matching) behavior as well.  In 
these cases, just require an extra explicit paren for the parameter list.  This 
would change the diff's to:

Example 1
-return columns.index { (column, _) in column.lowercased() == 
lowercaseName }
+   return columns.index { ((column, _)) in column.lowercased() == 
lowercaseName }

Example 2 :
-.map { (mappedColumn, baseColumn) -> (Int, String) in
+.map { ((mappedColumn, baseColumn)) -> (Int, String) in

Example 3 :
-.map { (table, columns) in 
"\(table)(\(columns.sorted().joined(separator: ", ")))" }   
+.map { ((table, columns)) in 
"\(table)(\(columns.sorted().joined(separator: ", ")))" } 

Example 4 :
-dictionary.first { (column, value) in column.lowercased() == 
orderedColumn.lowercased() }
+dictionary.first { ((column, value)) in column.lowercased() == 
orderedColumn.lowercased() }


What do you think?  Seems like it would solve the type checker problem, uglify 
the code a lot less, and make the fixit/migration happily trivial.

-Chris



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Simon Pilkington via swift-evolution]

I like the idea of the case let syntax option except for the fact that we have 
existing syntax for decomposing tuples that doesn’t use case-

let (_, age) = arg


Reusing this syntax feels like a better option than introducing a slight 
variant of it just for closures-


let eighteenOrMore = ["Tom" : 33, "Rebecca" : 17, "Siri" : 5].filter { let (_, 
age) in
  return age >= 18
}


-Simon

> On 2 Jun 2017, at 12:25 pm, Tommaso Piazza via swift-evolution 
>  wrote:
> 
> Thanks, added.
> 
> 
> On Friday, June 2, 2017 1:18 PM, Vladimir.S  wrote:
> 
> 
> On 02.06.2017 2:34, Tommaso Piazza wrote:
> > Is the version you suggest to add to my list for the Swift syntax currently 
> > valid as 
> > of SE-0110 in Swift 4?
> 
> Yes, just checked on latest dev snapshot of Swift 4.
> 
> > 
> > 
> > On Thursday, June 1, 2017 9:32 PM, Vladimir.S  > > wrote:
> > 
> > 
> > On 01.06.2017 19:31, Tommaso Piazza wrote:
> >  > Dear all,
> >  >
> >  > I made a comparison of Swift's 4 lack of tuple unsplatting, here is how 
> > it stands in
> >  > comparison with other languages
> >  >
> >  > https://gist.github.com/blender/53f9568617654c38a219dd4a8353d935 
> > 
> >  >
> > 
> > Thank you! Very useful information. And also I really like the opinion of
> > @AliSoftware in comments for this article.
> > 
> > I'd suggest to add this variant to Swift section in your article:
> > 
> > let eighteenOrMore = ["Tom" : 33, "Rebecca" : 17, "Siri" : 5].filter {
> >  (arg: (name: String, age: Int)) in arg.age >= 18 }
> > 
> > (I believe it is better that 2 others Swift variants.)
> > 
> > It seems for me that we need to allow some special syntax for *explicit* 
> > tuple
> > destructuring in closures to make all happy.
> > 
> > FWIW These suggestions are my favorite:
> > 
> > 1. Just allow type inference for tuple's destructured variables in this 
> > position:
> > 
> > .filter { (arg: (name, age)) in arg.age >= 18 }
> > 
> > 
> > 2. (1) + allow underscore for tuple argument name:
> > 
> > .filter { (_: (name, age)) in age >= 18 }
> > 
> > 
> > 3. (2) + allow to omit parenthesis (probably only in case of just one tuple 
> > argument)
> > 
> > .filter { _: (name, age) in age >= 18 }
> > 
> > 
> > 4. Use pattern matching syntax:
> > 
> > .filter { case let (name, age) in age >= 18 }
> > 
> > (looks similar as allowed today: if case let (name, age) = x { print(name, 
> > age) }  )
> > 
> > 
> > 5. Use two pairs of parenthesis :
> > 
> > .filter { ((name, age)) in age >= 18 }
> > 
> > Btw, about the 5th variant. If took what is allowed today:
> > .filter { (arg: (name: String, age: Int)) in arg.age >= 18 }
> > , and allow type inference for tuple part arguments, we'll have this:
> > .filter { (arg: (name, age)) in arg.age >= 18 }
> > , and if additionally allow skipping of tuple argument declaration we'll 
> > have:
> > .filter { ((name, age)) in arg.age >= 18 }
> > I.e. two pairs for parenthesis for tuple destructuring, and such syntax is 
> > similar to
> > the type this closure should have : ((String, Int)) -> Bool
> > 
> > 
> >  >
> >  >
> >  >
> >  > On Thursday, June 1, 2017 12:25 PM, Vladimir.S via swift-evolution
> >  >  
> > >> 
> > wrote:
> >  >
> >  >
> >  > On 01.06.2017 0:42, John McCall wrote:
> >  >  >> On May 31, 2017, at 2:02 PM, Stephen Celis  >  
> > >
> >  >  
> >  >  >  >>> On May 28, 2017, at 7:04 PM, John McCall via swift-evolution
> >  >  >>>  
> > > 
> >  
> >  > wrote:
> >  >  >>>
> >  >  >>> Yes, I agree.  We need to add back tuple destructuring in closure 
> > parameter
> >  >  >>> lists because this is a serious usability regression.  If we're 
> > reluctant to
> >  >  >>> just "do the right thing" to handle the ambiguity of (a,b), we 
> > should at least
> >  >  >>> allow it via unambiguous syntax like ((a,b)).  I do think that we 
> > should just
> >  >  >>> "do the right thing", however, with my biggest concern being 
> > whether there's
> >  >  >>> any reasonable way to achieve that in 4.0.
> >  >  >>
> >  >  >> Closure parameter lists are unfortunately only half of the equation 
> > here. This
> >  >  >> change also regresses the usability of point-free expression.
> >  >  >
> >  >  > The consequences for 

Re: [swift-evolution] Revisiting SE-0110

[Tommaso Piazza via swift-evolution]

Thanks, added. 

On Friday, June 2, 2017 1:18 PM, Vladimir.S  wrote:
 

 On 02.06.2017 2:34, Tommaso Piazza wrote:
> Is the version you suggest to add to my list for the Swift syntax currently 
> valid as 
> of SE-0110 in Swift 4?

Yes, just checked on latest dev snapshot of Swift 4.

> 
> 
> On Thursday, June 1, 2017 9:32 PM, Vladimir.S  wrote:
> 
> 
> On 01.06.2017 19:31, Tommaso Piazza wrote:
>  > Dear all,
>  >
>  > I made a comparison of Swift's 4 lack of tuple unsplatting, here is how it 
>stands in
>  > comparison with other languages
>  >
>  > https://gist.github.com/blender/53f9568617654c38a219dd4a8353d935
>  >
> 
> Thank you! Very useful information. And also I really like the opinion of
> @AliSoftware in comments for this article.
> 
> I'd suggest to add this variant to Swift section in your article:
> 
> let eighteenOrMore = ["Tom" : 33, "Rebecca" : 17, "Siri" : 5].filter {
>      (arg: (name: String, age: Int)) in arg.age >= 18 }
> 
> (I believe it is better that 2 others Swift variants.)
> 
> It seems for me that we need to allow some special syntax for *explicit* tuple
> destructuring in closures to make all happy.
> 
> FWIW These suggestions are my favorite:
> 
> 1. Just allow type inference for tuple's destructured variables in this 
> position:
> 
> .filter { (arg: (name, age)) in arg.age >= 18 }
> 
> 
> 2. (1) + allow underscore for tuple argument name:
> 
> .filter { (_: (name, age)) in age >= 18 }
> 
> 
> 3. (2) + allow to omit parenthesis (probably only in case of just one tuple 
> argument)
> 
> .filter { _: (name, age) in age >= 18 }
> 
> 
> 4. Use pattern matching syntax:
> 
> .filter { case let (name, age) in age >= 18 }
> 
> (looks similar as allowed today: if case let (name, age) = x { print(name, 
> age) }  )
> 
> 
> 5. Use two pairs of parenthesis :
> 
> .filter { ((name, age)) in age >= 18 }
> 
> Btw, about the 5th variant. If took what is allowed today:
> .filter { (arg: (name: String, age: Int)) in arg.age >= 18 }
> , and allow type inference for tuple part arguments, we'll have this:
> .filter { (arg: (name, age)) in arg.age >= 18 }
> , and if additionally allow skipping of tuple argument declaration we'll have:
> .filter { ((name, age)) in arg.age >= 18 }
> I.e. two pairs for parenthesis for tuple destructuring, and such syntax is 
> similar to
> the type this closure should have : ((String, Int)) -> Bool
> 
> 
>  >
>  >
>  >
>  > On Thursday, June 1, 2017 12:25 PM, Vladimir.S via swift-evolution
>  > > wrote:
>  >
>  >
>  > On 01.06.2017 0:42, John McCall wrote:
>  >  >> On May 31, 2017, at 2:02 PM, Stephen Celis  
>  > >> wrote:
>  >  >>> On May 28, 2017, at 7:04 PM, John McCall via swift-evolution
>  >  >>>  
> >> wrote:
>  >  >>>
>  >  >>> Yes, I agree.  We need to add back tuple destructuring in closure 
>parameter
>  >  >>> lists because this is a serious usability regression.  If we're 
>reluctant to
>  >  >>> just "do the right thing" to handle the ambiguity of (a,b), we should 
>at least
>  >  >>> allow it via unambiguous syntax like ((a,b)).  I do think that we 
>should just
>  >  >>> "do the right thing", however, with my biggest concern being whether 
>there's
>  >  >>> any reasonable way to achieve that in 4.0.
>  >  >>
>  >  >> Closure parameter lists are unfortunately only half of the equation 
>here. This
>  >  >> change also regresses the usability of point-free expression.
>  >  >
>  >  > The consequences for point-free style were expected and cannot really be
>  >  > eliminated without substantially weakening SE-0110.  Closure 
>convenience seems to
>  >  > me to be a much more serious regression.
>  >
>  > John, do you also want to say "and without weakening SE-0066"? Because, if 
>I
>  > understand correctly, in this case:
>  >
>  >    func add(_ x: Int, _ y: Int) -> Int {
>  >      return x + y
>  >    }
>  >
>  >    zip([1, 2, 3], [4, 5, 6]).map(add)
>  >
>  > .. we have a clear function type mismatch situation, when map() expects 
>function of
>  > type ((Int, Int))->Int, but function of type (Int,Int)->Int is provided ? 
>So probably
>  > the additional 'reason' of the 'problem' in this case is SE-0066, no?
>  > Or I don't understand the SE-0066 correctly..
>  > Do we want to allow implicit conversions between function type 
>((Int,Int))->Int and
>  > (Int,Int)->Int?
>  >
>  > Quote from SE-0066:
>  > ---
>  > (Int, Int) -> Int    // function from Int and Int to Int
>  > ((Int, Int)) -> Int  // function from tuple (Int, Int) to Int
>  > ---
>  >
>  > During this discussion I see a wish of some group of developers to just 
>return back
>  > tuple splatting for function/closure arguments, so they can 

Re: [swift-evolution] Revisiting SE-0110

[Vladimir.S via swift-evolution]

John and others, who are involved into this thread.
I'd suggest to clarify the current(Swift4) situation with function/closure type 
before we make any other decision and before continue to discuss the subject.
(sorry for long email, but I feel the problem with SE-0110 is wider than just "let's 
just drop it")


Please review this code and its result 
(swift-4.0-DEVELOPMENT-SNAPSHOT-2017-06-01-a-osx) :


func fooParam(_ x: Int, _ y: Int){}
func fooTuple(_ x: (Int, Int)) {}

print("type of fooParam is", type(of:fooParam))
// type of fooParam is (Int, Int) -> ()

print("type of fooTuple is", type(of:fooTuple))
// type of fooTuple is (Int, Int) -> ()

print("type of fooParam == type of fooTuple ?", type(of: fooParam) == type(of: 
fooTuple))

// true

if fooParam is (Int,Int)->() { print("fooParam is (Int,Int)->()") }
// fooParam is (Int,Int)->()

if fooParam is ((Int,Int))->() { print("fooParam is ((Int,Int))->()") }
// fooParam is ((Int,Int))->()

if fooTuple is (Int,Int)->() { print("fooTuple is (Int,Int)->()") }
// fooTuple is (Int,Int)->()

if fooTuple is ((Int,Int))->() { print("fooTuple is ((Int,Int))->()") }
// fooTuple is ((Int,Int))->()


var closureParam = { (x: Int, y: Int) in  }
var closureTuple = { (x: (Int, Int)) in  }

print("type of closureParam is", type(of:closureParam))
// type of closureParam is (Int, Int) -> ()

print("type of closureTuple is", type(of:closureTuple))
// type of closureTuple is (Int, Int) -> ()

if closureParam is (Int,Int)->() { print("closureParam is (Int,Int)->()") }
// closureParam is (Int,Int)->()

if closureParam is ((Int,Int))->() { print("closureParam is ((Int,Int))->()") }
// closureParam is ((Int,Int))->()

if closureTuple is (Int,Int)->() { print("closureTuple is (Int,Int)->()") }
// closureTuple is (Int,Int)->()

if closureTuple is ((Int,Int))->() { print("closureTuple is ((Int,Int))->()") }
// closureTuple is ((Int,Int))->()


func barParams(_ callback: (Int,Int)->()) { callback(1,2) }

//barParams(fooTuple)
//error: cannot convert value of type '((Int, Int)) -> ()' to expected argument type 
'(Int, Int) -> ()'


//barParams(closureTuple)
//error: cannot convert value of type '((Int, Int)) -> ()' to expected argument type 
'(Int, Int) -> ()'


func barTuple(_ callback: ((Int,Int))->()) { let tuple = (1,2); callback(tuple) 
}

//barTuple(fooParam)
//error: nested tuple parameter '(Int, Int)' of function '(((Int, Int)) -> ()) -> ()' 
does not support destructuring


//barTuple(closureParam)
//error: cannot convert value of type '(Int, Int) -> ()' to expected argument type 
'((Int, Int)) -> ()'



So, what is the type of fooParam/fooTuple/closureParam/closureTuple ?
Why the type is different in different situations?
Should we have strong and unambiguous type for functions/closures and probably *then* 
allow implicit conversion like "(Int,Int)->() can be used when ((Int,Int))->() is 
required and vise-versa"?


We have all this inconsistency with function/closure types from Swift 2, and this 
should be actually fixed in Swift 3, but still we are going to keep that in Swift 4.


Personally, I'm not against tuple deconstructing in closures and even think we can 
just have allowed implicit conversion between func/closure with single tuple argument 
and a list of arguments. But, I do believe we need consistent state in this area, 
strong types and clear rules. Because of this, if we have no time to implement good 
solution/workaround for Swift 4, I believe it is better to keep/fully implement 
SE-0110 and then provide solution for tuple destructuring. Otherwise we are going to 
have all these mess with func/closure types for very long time after Swift 4. Or we 
can try to implement a good workaround before release.


In current Swift 4 we are allowed for this:
.filter {(arg: (name: String, age: Int)) in arg.age >= 18 }

Is it really no way(before Swift 4 is released) to allow type inference for 'name' 
and 'age'? I believe this could be a good *workaround*, totally in Swift way(just 
like you can omit types for arguments in closure, or can specify them), this will 
keep the existed syntax for closure arguments and this will not prevent us from 
suggesting best solution after the Swift 4 release. And IMO this is acceptable 
compromise between loosing tuple deconstruction and keep the mess with 
function/closure type:

.filter {(arg: (name, age)) in arg.age >= 18 }

Or, as I said, just allow implicit conversion between function/closure types taking 
one tuple argument and a list of arguments. But still .filter should expect exactly 
((Int,String))->()  but it is allowed to send (Int,String)->() to it. All is strongly 
typed, but with magic "conversion".


I still believe that SE-0066 was the proposal that answered all these questions and 
said that (Int,Int)->() and ((Int,Int))->() are two different types. SE-0110 just 
clarified that the same rule should be applied to closures.
Until we started to discuss revisiting of SE-0110 I was under strong impression that 

Re: [swift-evolution] Revisiting SE-0110

[Vladimir.S via swift-evolution]

On 02.06.2017 2:34, Tommaso Piazza wrote:
Is the version you suggest to add to my list for the Swift syntax currently valid as 
of SE-0110 in Swift 4?


Yes, just checked on latest dev snapshot of Swift 4.




On Thursday, June 1, 2017 9:32 PM, Vladimir.S  wrote:


On 01.06.2017 19:31, Tommaso Piazza wrote:
 > Dear all,
 >
 > I made a comparison of Swift's 4 lack of tuple unsplatting, here is how it 
stands in
 > comparison with other languages
 >
 > https://gist.github.com/blender/53f9568617654c38a219dd4a8353d935
 >

Thank you! Very useful information. And also I really like the opinion of
@AliSoftware in comments for this article.

I'd suggest to add this variant to Swift section in your article:

let eighteenOrMore = ["Tom" : 33, "Rebecca" : 17, "Siri" : 5].filter {
 (arg: (name: String, age: Int)) in arg.age >= 18 }

(I believe it is better that 2 others Swift variants.)

It seems for me that we need to allow some special syntax for *explicit* tuple
destructuring in closures to make all happy.

FWIW These suggestions are my favorite:

1. Just allow type inference for tuple's destructured variables in this 
position:

.filter { (arg: (name, age)) in arg.age >= 18 }


2. (1) + allow underscore for tuple argument name:

.filter { (_: (name, age)) in age >= 18 }


3. (2) + allow to omit parenthesis (probably only in case of just one tuple 
argument)

.filter { _: (name, age) in age >= 18 }


4. Use pattern matching syntax:

.filter { case let (name, age) in age >= 18 }

(looks similar as allowed today: if case let (name, age) = x { print(name, age) 
}  )


5. Use two pairs of parenthesis :

.filter { ((name, age)) in age >= 18 }

Btw, about the 5th variant. If took what is allowed today:
.filter { (arg: (name: String, age: Int)) in arg.age >= 18 }
, and allow type inference for tuple part arguments, we'll have this:
.filter { (arg: (name, age)) in arg.age >= 18 }
, and if additionally allow skipping of tuple argument declaration we'll have:
.filter { ((name, age)) in arg.age >= 18 }
I.e. two pairs for parenthesis for tuple destructuring, and such syntax is 
similar to
the type this closure should have : ((String, Int)) -> Bool


 >
 >
 >
 > On Thursday, June 1, 2017 12:25 PM, Vladimir.S via swift-evolution
 > > wrote:
 >
 >
 > On 01.06.2017 0:42, John McCall wrote:
 >  >> On May 31, 2017, at 2:02 PM, Stephen Celis 

 > >> wrote:
 >  >>> On May 28, 2017, at 7:04 PM, John McCall via swift-evolution
 >  >>>  
>> wrote:

 >  >>>
 >  >>> Yes, I agree.  We need to add back tuple destructuring in closure 
parameter
 >  >>> lists because this is a serious usability regression.  If we're 
reluctant to
 >  >>> just "do the right thing" to handle the ambiguity of (a,b), we should 
at least
 >  >>> allow it via unambiguous syntax like ((a,b)).  I do think that we 
should just
 >  >>> "do the right thing", however, with my biggest concern being whether 
there's
 >  >>> any reasonable way to achieve that in 4.0.
 >  >>
 >  >> Closure parameter lists are unfortunately only half of the equation 
here. This
 >  >> change also regresses the usability of point-free expression.
 >  >
 >  > The consequences for point-free style were expected and cannot really be
 >  > eliminated without substantially weakening SE-0110.  Closure convenience 
seems to
 >  > me to be a much more serious regression.
 >
 > John, do you also want to say "and without weakening SE-0066"? Because, if I
 > understand correctly, in this case:
 >
 >func add(_ x: Int, _ y: Int) -> Int {
 >  return x + y
 >}
 >
 >zip([1, 2, 3], [4, 5, 6]).map(add)
 >
 > .. we have a clear function type mismatch situation, when map() expects 
function of
 > type ((Int, Int))->Int, but function of type (Int,Int)->Int is provided ? So 
probably
 > the additional 'reason' of the 'problem' in this case is SE-0066, no?
 > Or I don't understand the SE-0066 correctly..
 > Do we want to allow implicit conversions between function type 
((Int,Int))->Int and
 > (Int,Int)->Int?
 >
 > Quote from SE-0066:
 > ---
 > (Int, Int) -> Int// function from Int and Int to Int
 > ((Int, Int)) -> Int  // function from tuple (Int, Int) to Int
 > ---
 >
 > During this discussion I see a wish of some group of developers to just 
return back
 > tuple splatting for function/closure arguments, so they can freely send 
tuple to
 > function/closure accepting a list of parameters(and probably vise-versa).
 > Is it worth to follow SE-0066 and SE-0110 as is, i.e. disallow tuple 
deconstructing
 > and then, as additive change improve the situation with tuple
 > splatting/deconstructing later with separate big proposal?
 >
 > Btw, about the SE-0110 proposal. It 

Re: [swift-evolution] Revisiting SE-0110

[Víctor Pimentel Rodríguez via swift-evolution]

On Fri, Jun 2, 2017 at 1:53 AM, Jonathan Hull via swift-evolution <
swift-evolution@swift.org> wrote:

> I vote to revert it to current behavior.  Then we can take time to come up
> with the correct answer for future Swift.
>
> If we don’t revert and then end up changing it again later, we will break
> everybody’s code twice...
>
> Thanks,
> Jon
>

+1

This source-breaking change affects lots of libraries, as it has been
shown. It seems very late in Swift 4 to be discussing alternative syntaxes,
so the best action for me would be revert it and revisit this in the next
version.

-- 
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Pavol Vaskovic via swift-evolution]

On Fri, Jun 2, 2017 at 12:06 AM, John McCall  wrote:

>
> You're misunderstanding me.  I have explicitly said, several times, that I
> agree that the impact on tuple destructuring in closures is a serious
> regression.  There have *also* been objections to losing argument-splat
> behavior, and while that does negatively affect some functional styles, I
> think it would be a mistake to try to address that now.
>

Ah, now I understand. You were talking about the example brought up by
Stephen Celis, where they `map` over tupples from zipped sequence with
`add` function that takes two arguments and the they had to adapt with
`tuppleUp` function.

I'm sorry for the misunderstanding!

--Pavol
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Jonathan Hull via swift-evolution]

I vote to revert it to current behavior.  Then we can take time to come up with 
the correct answer for future Swift.

If we don’t revert and then end up changing it again later, we will break 
everybody’s code twice...

Thanks,
Jon


> On Jun 1, 2017, at 2:39 PM, Pavol Vaskovic via swift-evolution 
>  wrote:
> 
> On Thu, Jun 1, 2017 at 8:52 PM, John McCall via swift-evolution 
> > wrote:
> 
> I understand that there are developers who dislike SE-0110's impact on 
> certain kinds of functional programming, but that is a very broad complaint 
> that is unlikely to reach consensus or acceptance, especially for Swift 4. 
> 
> The impact of SE-0110 as currently implemented in Swift 4 leads to following 
> migration choice wherever you have a closure that takes tuple argument:
> * concise but obfuscate code ($0.1, ...)
> * readable but verbose code (requiring a ton of boilerplate: intermediate 
> argument, expand signature to include return type, desctructure tuple on new 
> line using let, add return clause)
> 
> Maybe I misunderstood you, but I don't think this is marginal issue affecting 
> only some "developers that dislike the impact on certain kinds of functional 
> programming". 
> 
> This is a HUGE regression to the usability of all closure with tuple 
> arguments. I'd wager that is the prevailing consensual opinion of anyone who 
> has experienced this issue in practice. 
> 
> I would go as far as to claim that current implementation of SE-0110 does not 
> conform to the Swift 4's goal of backwards source compatibility.
>  
> In contrast, I think we may be able to gain consensus on a more targeted 
> proposal that just re-admits tuple destructuring in closures, assuming we can 
> find an acceptable implementation.
> 
> From what I understand our options are quite limited because of tight 
> constraints of Swift 4's emphasis on backwards source-compatibility and 
> impending release deadline:
> 
> * effectively revert SE-0110 by always using the codepath for Swift 3 
> compatibility mode
> * implement full tuple destructuring (unexplored issues with syntax and 
> backwards compatibility)
> 
> (Note that Swift 3 didn't support full tuple destructuring - SR-4738 
> )
> 
> --Pavol
> ___
> 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

Re: [swift-evolution] Revisiting SE-0110

[Tommaso Piazza via swift-evolution]

Is the version you suggest to add to my list for the Swift syntax currently 
valid as of SE-0110 in Swift 4? 

On Thursday, June 1, 2017 9:32 PM, Vladimir.S  wrote:
 

 On 01.06.2017 19:31, Tommaso Piazza wrote:
> Dear all,
> 
> I made a comparison of Swift's 4 lack of tuple unsplatting, here is how it 
> stands in 
> comparison with other languages
> 
> https://gist.github.com/blender/53f9568617654c38a219dd4a8353d935
> 

Thank you! Very useful information. And also I really like the opinion of 
@AliSoftware in comments for this article.

I'd suggest to add this variant to Swift section in your article:

let eighteenOrMore = ["Tom" : 33, "Rebecca" : 17, "Siri" : 5].filter {
    (arg: (name: String, age: Int)) in arg.age >= 18 }

(I believe it is better that 2 others Swift variants.)

It seems for me that we need to allow some special syntax for *explicit* tuple 
destructuring in closures to make all happy.

FWIW These suggestions are my favorite:

1. Just allow type inference for tuple's destructured variables in this 
position:

.filter { (arg: (name, age)) in arg.age >= 18 }


2. (1) + allow underscore for tuple argument name:

.filter { (_: (name, age)) in age >= 18 }


3. (2) + allow to omit parenthesis (probably only in case of just one tuple 
argument)

.filter { _: (name, age) in age >= 18 }


4. Use pattern matching syntax:

.filter { case let (name, age) in age >= 18 }

(looks similar as allowed today: if case let (name, age) = x { print(name, age) 
}  )


5. Use two pairs of parenthesis :

.filter { ((name, age)) in age >= 18 }

Btw, about the 5th variant. If took what is allowed today:
.filter { (arg: (name: String, age: Int)) in arg.age >= 18 }
, and allow type inference for tuple part arguments, we'll have this:
.filter { (arg: (name, age)) in arg.age >= 18 }
, and if additionally allow skipping of tuple argument declaration we'll have:
.filter { ((name, age)) in arg.age >= 18 }
I.e. two pairs for parenthesis for tuple destructuring, and such syntax is 
similar to 
the type this closure should have : ((String, Int)) -> Bool


> 
> 
> 
> On Thursday, June 1, 2017 12:25 PM, Vladimir.S via swift-evolution 
>  wrote:
> 
> 
> On 01.06.2017 0:42, John McCall wrote:
>  >> On May 31, 2017, at 2:02 PM, Stephen Celis  > wrote:
>  >>> On May 28, 2017, at 7:04 PM, John McCall via swift-evolution
>  >>> > wrote:
>  >>>
>  >>> Yes, I agree.  We need to add back tuple destructuring in closure 
>parameter
>  >>> lists because this is a serious usability regression.  If we're 
>reluctant to
>  >>> just "do the right thing" to handle the ambiguity of (a,b), we should at 
>least
>  >>> allow it via unambiguous syntax like ((a,b)).  I do think that we should 
>just
>  >>> "do the right thing", however, with my biggest concern being whether 
>there's
>  >>> any reasonable way to achieve that in 4.0.
>  >>
>  >> Closure parameter lists are unfortunately only half of the equation here. 
>This
>  >> change also regresses the usability of point-free expression.
>  >
>  > The consequences for point-free style were expected and cannot really be
>  > eliminated without substantially weakening SE-0110.  Closure convenience 
>seems to
>  > me to be a much more serious regression.
> 
> John, do you also want to say "and without weakening SE-0066"? Because, if I
> understand correctly, in this case:
> 
>    func add(_ x: Int, _ y: Int) -> Int {
>      return x + y
>    }
> 
>    zip([1, 2, 3], [4, 5, 6]).map(add)
> 
> .. we have a clear function type mismatch situation, when map() expects 
> function of
> type ((Int, Int))->Int, but function of type (Int,Int)->Int is provided ? So 
> probably
> the additional 'reason' of the 'problem' in this case is SE-0066, no?
> Or I don't understand the SE-0066 correctly..
> Do we want to allow implicit conversions between function type 
> ((Int,Int))->Int and
> (Int,Int)->Int?
> 
> Quote from SE-0066:
> ---
> (Int, Int) -> Int    // function from Int and Int to Int
> ((Int, Int)) -> Int  // function from tuple (Int, Int) to Int
> ---
> 
> During this discussion I see a wish of some group of developers to just 
> return back
> tuple splatting for function/closure arguments, so they can freely send tuple 
> to
> function/closure accepting a list of parameters(and probably vise-versa).
> Is it worth to follow SE-0066 and SE-0110 as is, i.e. disallow tuple 
> deconstructing
> and then, as additive change improve the situation with tuple
> splatting/deconstructing later with separate big proposal?
> 
> Btw, about the SE-0110 proposal. It was discussed, formally reviewed and 
> accepted. I
> expect that its revision also should be formally proposed/reviewed/accepted to
> collect a wide range of opinions and thoughts, and attract the attention of
> developers in this list to the subject.
> 
> 
> Also, if we revisit SE-0110, 

Re: [swift-evolution] Revisiting SE-0110

[John McCall via swift-evolution]

> On Jun 1, 2017, at 2:39 PM, Pavol Vaskovic  wrote:
> 
> On Thu, Jun 1, 2017 at 8:52 PM, John McCall via swift-evolution 
> > wrote:
> 
> I understand that there are developers who dislike SE-0110's impact on 
> certain kinds of functional programming, but that is a very broad complaint 
> that is unlikely to reach consensus or acceptance, especially for Swift 4. 
> 
> The impact of SE-0110 as currently implemented in Swift 4 leads to following 
> migration choice wherever you have a closure that takes tuple argument:
> * concise but obfuscate code ($0.1, ...)
> * readable but verbose code (requiring a ton of boilerplate: intermediate 
> argument, expand signature to include return type, desctructure tuple on new 
> line using let, add return clause)
> 
> Maybe I misunderstood you, but I don't think this is marginal issue affecting 
> only some "developers that dislike the impact on certain kinds of functional 
> programming". 

You're misunderstanding me.  I have explicitly said, several times, that I 
agree that the impact on tuple destructuring in closures is a serious 
regression.  There have *also* been objections to losing argument-splat 
behavior, and while that does negatively affect some functional styles, I think 
it would be a mistake to try to address that now.

John.

> 
> This is a HUGE regression to the usability of all closure with tuple 
> arguments. I'd wager that is the prevailing consensual opinion of anyone who 
> has experienced this issue in practice. 
> 
> I would go as far as to claim that current implementation of SE-0110 does not 
> conform to the Swift 4's goal of backwards source compatibility.
>  
> In contrast, I think we may be able to gain consensus on a more targeted 
> proposal that just re-admits tuple destructuring in closures, assuming we can 
> find an acceptable implementation.
> 
> From what I understand our options are quite limited because of tight 
> constraints of Swift 4's emphasis on backwards source-compatibility and 
> impending release deadline:
> 
> * effectively revert SE-0110 by always using the codepath for Swift 3 
> compatibility mode
> * implement full tuple destructuring (unexplored issues with syntax and 
> backwards compatibility)
> 
> (Note that Swift 3 didn't support full tuple destructuring - SR-4738 
> )
> 
> --Pavol

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Pavol Vaskovic via swift-evolution]

On Thu, Jun 1, 2017 at 8:52 PM, John McCall via swift-evolution <
swift-evolution@swift.org> wrote:

>
> I understand that there are developers who dislike SE-0110's impact on
> certain kinds of functional programming, but that is a very broad complaint
> that is unlikely to reach consensus or acceptance, especially for Swift 4.


The impact of SE-0110 as currently implemented in Swift 4 leads to
following migration choice wherever you have a closure that takes tuple
argument:
* concise but obfuscate code ($0.1, ...)
* readable but verbose code (requiring a ton of boilerplate: intermediate
argument, expand signature to include return type, desctructure tuple on
new line using let, add return clause)

Maybe I misunderstood you, but I don't think this is marginal issue
affecting only some "developers that dislike the impact on certain kinds of
functional programming".

This is a HUGE regression to the usability of all closure with tuple
arguments. I'd wager that is the prevailing consensual opinion of anyone
who has experienced this issue in practice.

I would go as far as to claim that current implementation of SE-0110 does
not conform to the Swift 4's goal of backwards source compatibility.


> In contrast, I think we may be able to gain consensus on a more targeted
> proposal that just re-admits tuple destructuring in closures, assuming we
> can find an acceptable implementation.


>From what I understand our options are quite limited because of tight
constraints of Swift 4's emphasis on backwards source-compatibility and
impending release deadline:

* effectively revert SE-0110 by always using the codepath for Swift 3
compatibility mode
* implement full tuple destructuring (unexplored issues with syntax and
backwards compatibility)

(Note that Swift 3 didn't support full tuple destructuring - SR-4738
)

--Pavol
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Paul Cantrell via swift-evolution]

To add more real-world project data to this discussion, I just did a test 
migration of Siesta to Swift 4 using the 2017-05-30 snapshot.

Nothing earth-shattering follows — just more practical evidence that the 
problem needs attention.

Here’s what I found:

(1) The lack of tuple destructing under discussion here hit the project in half 
a dozen places. That’s in only a ~2k-line codebase.

(2) Every one of those places it hit involved a Dictionary.

Most involved calling map, flatMap, or filter, so adding Dictionary-specific 
2-arg flavors of those methods to stdlib would reduce the burden of SE-110. 
However, some places involved custom Collection extensions (e.g. “any”), so 
it’s not just the stdlib that would have to add nearly-redundant 
dictionary-specific variants of Collection methods. Destructuring still has a 
clear advantage.

(3) All the problems were indeed fixable using $0.0 and $0.1 in place of named 
destructured args, but the damage to readability was … severe. Compare this, 
for example:

let nonEmptyStages = stages
.filter { _, stage in !stage.isEmpty }
.map { key, _ in key }

…to this:

let nonEmptyStages = stages
.filter { !$0.1.isEmpty }
.map { $0.0 }

Even though “stage” conveys little information, and “key” even less, the net 
gain from those named args is large, at least to my eyes.

(4) SE-110 is also the thing that prevents Siesta’s dependencies from compiling.

Hope all this helps weigh the tradeoffs of taking this on.

Cheers,

Paul

> On Jun 1, 2017, at 2:32 PM, Vladimir.S via swift-evolution 
>  wrote:
> 
> On 01.06.2017 19:31, Tommaso Piazza wrote:
>> Dear all,
>> I made a comparison of Swift's 4 lack of tuple unsplatting, here is how it 
>> stands in comparison with other languages
>> https://gist.github.com/blender/53f9568617654c38a219dd4a8353d935
> 
> Thank you! Very useful information. And also I really like the opinion of 
> @AliSoftware in comments for this article.
> 
> I'd suggest to add this variant to Swift section in your article:
> 
> let eighteenOrMore = ["Tom" : 33, "Rebecca" : 17, "Siri" : 5].filter {
>   (arg: (name: String, age: Int)) in arg.age >= 18 }
> 
> (I believe it is better that 2 others Swift variants.)
> 
> It seems for me that we need to allow some special syntax for *explicit* 
> tuple destructuring in closures to make all happy.
> 
> FWIW These suggestions are my favorite:
> 
> 1. Just allow type inference for tuple's destructured variables in this 
> position:
> 
> .filter { (arg: (name, age)) in arg.age >= 18 }
> 
> 
> 2. (1) + allow underscore for tuple argument name:
> 
> .filter { (_: (name, age)) in age >= 18 }
> 
> 
> 3. (2) + allow to omit parenthesis (probably only in case of just one tuple 
> argument)
> 
> .filter { _: (name, age) in age >= 18 }
> 
> 
> 4. Use pattern matching syntax:
> 
> .filter { case let (name, age) in age >= 18 }
> 
> (looks similar as allowed today: if case let (name, age) = x { print(name, 
> age) }  )
> 
> 
> 5. Use two pairs of parenthesis :
> 
> .filter { ((name, age)) in age >= 18 }
> 
> Btw, about the 5th variant. If took what is allowed today:
> .filter { (arg: (name: String, age: Int)) in arg.age >= 18 }
> , and allow type inference for tuple part arguments, we'll have this:
> .filter { (arg: (name, age)) in arg.age >= 18 }
> , and if additionally allow skipping of tuple argument declaration we'll have:
> .filter { ((name, age)) in arg.age >= 18 }
> I.e. two pairs for parenthesis for tuple destructuring, and such syntax is 
> similar to the type this closure should have : ((String, Int)) -> Bool
> 
> 
>> On Thursday, June 1, 2017 12:25 PM, Vladimir.S via swift-evolution 
>>  wrote:
>> On 01.06.2017 0:42, John McCall wrote:
>> >> On May 31, 2017, at 2:02 PM, Stephen Celis > >> > wrote:
>> >>> On May 28, 2017, at 7:04 PM, John McCall via swift-evolution
>> >>> > wrote:
>> >>>
>> >>> Yes, I agree.  We need to add back tuple destructuring in closure 
>> >>> parameter
>> >>> lists because this is a serious usability regression.  If we're 
>> >>> reluctant to
>> >>> just "do the right thing" to handle the ambiguity of (a,b), we should at 
>> >>> least
>> >>> allow it via unambiguous syntax like ((a,b)).  I do think that we should 
>> >>> just
>> >>> "do the right thing", however, with my biggest concern being whether 
>> >>> there's
>> >>> any reasonable way to achieve that in 4.0.
>> >>
>> >> Closure parameter lists are unfortunately only half of the equation here. 
>> >> This
>> >> change also regresses the usability of point-free expression.
>> >
>> > The consequences for point-free style were expected and cannot really be
>> > eliminated without substantially weakening SE-0110.  Closure convenience 
>> > seems to
>> > me to be a much more serious regression.
>> John, do you also want to say 

Re: [swift-evolution] Revisiting SE-0110

[Vladimir.S via swift-evolution]

On 01.06.2017 21:52, John McCall wrote:



On Jun 1, 2017, at 3:25 AM, Vladimir.S  wrote:

On 01.06.2017 0:42, John McCall wrote:

On May 31, 2017, at 2:02 PM, Stephen Celis  wrote:
On May 28, 2017, at 7:04 PM, John McCall via swift-evolution 
 wrote: Yes, I agree.  We need to add back

tuple destructuring in closure parameter lists because this is a serious
usability regression.  If we're reluctant to just "do the right thing" to
handle the ambiguity of (a,b), we should at least allow it via unambiguous
syntax like ((a,b)).  I do think that we should just "do the right thing",
however, with my biggest concern being whether there's any reasonable way
to achieve that in 4.0.

Closure parameter lists are unfortunately only half of the equation here.
This change also regresses the usability of point-free expression.
The consequences for point-free style were expected and cannot really be 
eliminated without substantially weakening SE-0110.  Closure convenience seems

to me to be a much more serious regression.


John, do you also want to say "and without weakening SE-0066"? Because, if I
understand correctly, in this case:


No.  SE-0066 was ultimately just a syntax proposal.  SE-0110 clarified the


Hmm. Could you please comment this(below) part of SE-0066? :

--
Proposed solution

Parentheses will be required in *function types*. Examples:

Int -> Int   // error
(Int) -> Int // function from Int to Int
((Int)) -> Int   // also function from Int to Int

Int, Int -> Int  // error
(Int, Int) -> Int// function from Int and Int to Int
((Int, Int)) -> Int  // function from tuple (Int, Int) to Int
...
--



intended type-system behavior of function types for both calls and conversions.
Removing tuple destructuring from parameter clauses was an incidental 
consequence
of that, which in my opinion was pursued out of enthusiasm and without 
adequately
understanding the impact on closures.


Well, I still believe SE-0110 was inspired by SE-0066 in a way how function types 
were described in the latter.


Do you want to say, that if SE-0110 was not accepted(but SE-0066 is accepted), 
function that takes one tuple parameter for example func foo(_ x: (Int, Int)){} will 
still be of *type* (Int,Int)->Void and not ((Int,Int))->Void ?


And I'd still ask, if you have some time, please answer the question regarding the 
closure type and allowed code(in the same email you replied just below) in case we 
revisit SE-0110 *or* SE-0110 was not ever be proposed
(I'm afraid I'm missing something very important about SE-0066 and function type 
differences we should have in Swift 4). Thank you.


Vladimir.



I understand that there are developers who dislike SE-0110's impact on certain
kinds of functional programming, but that is a very broad complaint that is
unlikely to reach consensus or acceptance, especially for Swift 4.  In 
contrast, I
think we may be able to gain consensus on a more targeted proposal that just
re-admits tuple destructuring in closures, assuming we can find an acceptable
implementation.

John.


func add(_ x: Int, _ y: Int) -> Int { return x + y }

zip([1, 2, 3], [4, 5, 6]).map(add)

.. we have a clear function type mismatch situation, when map() expects function
of type ((Int, Int))->Int, but function of type (Int,Int)->Int is provided ? So
probably the additional 'reason' of the 'problem' in this case is SE-0066, no? 
Or I don't understand the SE-0066 correctly.. Do we want to allow implicit

conversions between function type ((Int,Int))->Int and (Int,Int)->Int?

Quote from SE-0066: --- (Int, Int) -> Int// function from Int and Int to
Int ((Int, Int)) -> Int  // function from tuple (Int, Int) to Int ---

During this discussion I see a wish of some group of developers to just return
back tuple splatting for function/closure arguments, so they can freely send
tuple to function/closure accepting a list of parameters(and probably
vise-versa). Is it worth to follow SE-0066 and SE-0110 as is, i.e. disallow
tuple deconstructing and then, as additive change improve the situation with
tuple splatting/deconstructing later with separate big proposal?

Btw, about the SE-0110 proposal. It was discussed, formally reviewed and
accepted. I expect that its revision also should be formally
proposed/reviewed/accepted to collect a wide range of opinions and thoughts, and
attract the attention of developers in this list to the subject.


Also, if we revisit SE-0110, will this code be allowed?:

func foo(_ callback: ((Int,Int))->Void) {} let mycallback = {(x:Int,
y:Int)->Void in } foo(mycallback)

and

func foo(_ callback: (Int,Int)->Void) {} let mycallback = {(x: (Int, Int))->Void
in } foo(mycallback)

If so, what will be result of this for both cases? :

print(type(of:mycallback)) // (Int,Int)->Void or ((Int,Int))->Void

If allowed, do we want to allow implicit conversion between types
(Int,Int)->Void and 

Re: [swift-evolution] Revisiting SE-0110

[Vladimir.S via swift-evolution]

On 01.06.2017 22:46, T.J. Usiyan wrote:
I, for one, would be willing to accept Xiaodi's suggestion involving `let`–especially 
if (pipe dream follows) we could use the same syntax in functions/methods to 
destructure parameters.


Yes, Xiaodi's suggestion also was very attractive. Just to remind:
--
{ (a, b) -> Int in } // two parameters
{ let (a, b) -> Int in } // destructuring one parameter

{ a, let (b, c) -> Int in } // destructuring two parameters
{ let a, (b, c) -> Int in } // still destructuring two parameters
{ let (a, (b, c)) -> Int in } // destructuring one parameter
{ (a, (b, c)) -> Int in } // error: add 'let' to destructure second parameter
--



On Thu, Jun 1, 2017 at 3:32 PM, Vladimir.S via swift-evolution 
> wrote:


On 01.06.2017 19:31, Tommaso Piazza wrote:

Dear all,

I made a comparison of Swift's 4 lack of tuple unsplatting, here is how 
it
stands in comparison with other languages

https://gist.github.com/blender/53f9568617654c38a219dd4a8353d935



Thank you! Very useful information. And also I really like the opinion of
@AliSoftware in comments for this article.

I'd suggest to add this variant to Swift section in your article:

let eighteenOrMore = ["Tom" : 33, "Rebecca" : 17, "Siri" : 5].filter {
 (arg: (name: String, age: Int)) in arg.age >= 18 }

(I believe it is better that 2 others Swift variants.)

It seems for me that we need to allow some special syntax for *explicit* 
tuple
destructuring in closures to make all happy.

FWIW These suggestions are my favorite:

1. Just allow type inference for tuple's destructured variables in this 
position:

.filter { (arg: (name, age)) in arg.age >= 18 }


2. (1) + allow underscore for tuple argument name:

.filter { (_: (name, age)) in age >= 18 }


3. (2) + allow to omit parenthesis (probably only in case of just one tuple 
argument)

.filter { _: (name, age) in age >= 18 }


4. Use pattern matching syntax:

.filter { case let (name, age) in age >= 18 }

(looks similar as allowed today: if case let (name, age) = x { print(name, 
age) }  )


5. Use two pairs of parenthesis :

.filter { ((name, age)) in age >= 18 }

Btw, about the 5th variant. If took what is allowed today:
.filter { (arg: (name: String, age: Int)) in arg.age >= 18 }
, and allow type inference for tuple part arguments, we'll have this:
.filter { (arg: (name, age)) in arg.age >= 18 }
, and if additionally allow skipping of tuple argument declaration we'll 
have:
.filter { ((name, age)) in arg.age >= 18 }
I.e. two pairs for parenthesis for tuple destructuring, and such syntax is
similar to the type this closure should have : ((String, Int)) -> Bool





On Thursday, June 1, 2017 12:25 PM, Vladimir.S via swift-evolution
> wrote:


On 01.06.2017 0:42, John McCall wrote:
  >> On May 31, 2017, at 2:02 PM, Stephen Celis  >> wrote:
  >>> On May 28, 2017, at 7:04 PM, John McCall via swift-evolution
  >>> 
>> 
wrote:
  >>>
  >>> Yes, I agree.  We need to add back tuple destructuring in closure 
parameter
  >>> lists because this is a serious usability regression.  If we're
reluctant to
  >>> just "do the right thing" to handle the ambiguity of (a,b), we 
should
at least
  >>> allow it via unambiguous syntax like ((a,b)).  I do think that we
should just
  >>> "do the right thing", however, with my biggest concern being 
whether
there's
  >>> any reasonable way to achieve that in 4.0.
  >>
  >> Closure parameter lists are unfortunately only half of the equation
here. This
  >> change also regresses the usability of point-free expression.
  >
  > The consequences for point-free style were expected and cannot 
really be
  > eliminated without substantially weakening SE-0110.  Closure 
convenience
seems to
  > me to be a much more serious regression.

John, do you also want to say "and without weakening SE-0066"? Because, 
if I
understand correctly, in this case:

func add(_ x: Int, _ y: Int) -> Int {
  return x + y
}

zip([1, 2, 3], [4, 5, 6]).map(add)

.. we have a clear function type mismatch situation, when map() expects
function of
type ((Int, Int))->Int, but 

Re: [swift-evolution] Revisiting SE-0110

[T.J. Usiyan via swift-evolution]

I, for one, would be willing to accept Xiaodi's suggestion involving
`let`–especially if (pipe dream follows) we could use the same syntax in
functions/methods to destructure parameters.

On Thu, Jun 1, 2017 at 3:32 PM, Vladimir.S via swift-evolution <
swift-evolution@swift.org> wrote:

> On 01.06.2017 19:31, Tommaso Piazza wrote:
>
>> Dear all,
>>
>> I made a comparison of Swift's 4 lack of tuple unsplatting, here is how
>> it stands in comparison with other languages
>>
>> https://gist.github.com/blender/53f9568617654c38a219dd4a8353d935
>>
>>
> Thank you! Very useful information. And also I really like the opinion of
> @AliSoftware in comments for this article.
>
> I'd suggest to add this variant to Swift section in your article:
>
> let eighteenOrMore = ["Tom" : 33, "Rebecca" : 17, "Siri" : 5].filter {
> (arg: (name: String, age: Int)) in arg.age >= 18 }
>
> (I believe it is better that 2 others Swift variants.)
>
> It seems for me that we need to allow some special syntax for *explicit*
> tuple destructuring in closures to make all happy.
>
> FWIW These suggestions are my favorite:
>
> 1. Just allow type inference for tuple's destructured variables in this
> position:
>
> .filter { (arg: (name, age)) in arg.age >= 18 }
>
>
> 2. (1) + allow underscore for tuple argument name:
>
> .filter { (_: (name, age)) in age >= 18 }
>
>
> 3. (2) + allow to omit parenthesis (probably only in case of just one
> tuple argument)
>
> .filter { _: (name, age) in age >= 18 }
>
>
> 4. Use pattern matching syntax:
>
> .filter { case let (name, age) in age >= 18 }
>
> (looks similar as allowed today: if case let (name, age) = x { print(name,
> age) }  )
>
>
> 5. Use two pairs of parenthesis :
>
> .filter { ((name, age)) in age >= 18 }
>
> Btw, about the 5th variant. If took what is allowed today:
> .filter { (arg: (name: String, age: Int)) in arg.age >= 18 }
> , and allow type inference for tuple part arguments, we'll have this:
> .filter { (arg: (name, age)) in arg.age >= 18 }
> , and if additionally allow skipping of tuple argument declaration we'll
> have:
> .filter { ((name, age)) in arg.age >= 18 }
> I.e. two pairs for parenthesis for tuple destructuring, and such syntax is
> similar to the type this closure should have : ((String, Int)) -> Bool
>
>
>
>>
>>
>> On Thursday, June 1, 2017 12:25 PM, Vladimir.S via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> On 01.06.2017 0:42, John McCall wrote:
>>  >> On May 31, 2017, at 2:02 PM, Stephen Celis > > wrote:
>>  >>> On May 28, 2017, at 7:04 PM, John McCall via swift-evolution
>>  >>> >
>> wrote:
>>  >>>
>>  >>> Yes, I agree.  We need to add back tuple destructuring in closure
>> parameter
>>  >>> lists because this is a serious usability regression.  If we're
>> reluctant to
>>  >>> just "do the right thing" to handle the ambiguity of (a,b), we
>> should at least
>>  >>> allow it via unambiguous syntax like ((a,b)).  I do think that we
>> should just
>>  >>> "do the right thing", however, with my biggest concern being whether
>> there's
>>  >>> any reasonable way to achieve that in 4.0.
>>  >>
>>  >> Closure parameter lists are unfortunately only half of the equation
>> here. This
>>  >> change also regresses the usability of point-free expression.
>>  >
>>  > The consequences for point-free style were expected and cannot really
>> be
>>  > eliminated without substantially weakening SE-0110.  Closure
>> convenience seems to
>>  > me to be a much more serious regression.
>>
>> John, do you also want to say "and without weakening SE-0066"? Because,
>> if I
>> understand correctly, in this case:
>>
>>func add(_ x: Int, _ y: Int) -> Int {
>>  return x + y
>>}
>>
>>zip([1, 2, 3], [4, 5, 6]).map(add)
>>
>> .. we have a clear function type mismatch situation, when map() expects
>> function of
>> type ((Int, Int))->Int, but function of type (Int,Int)->Int is provided ?
>> So probably
>> the additional 'reason' of the 'problem' in this case is SE-0066, no?
>> Or I don't understand the SE-0066 correctly..
>> Do we want to allow implicit conversions between function type
>> ((Int,Int))->Int and
>> (Int,Int)->Int?
>>
>> Quote from SE-0066:
>> ---
>> (Int, Int) -> Int// function from Int and Int to Int
>> ((Int, Int)) -> Int  // function from tuple (Int, Int) to Int
>> ---
>>
>> During this discussion I see a wish of some group of developers to just
>> return back
>> tuple splatting for function/closure arguments, so they can freely send
>> tuple to
>> function/closure accepting a list of parameters(and probably vise-versa).
>> Is it worth to follow SE-0066 and SE-0110 as is, i.e. disallow tuple
>> deconstructing
>> and then, as additive change improve the situation with tuple
>> splatting/deconstructing later with separate big proposal?
>>
>> Btw, about the SE-0110 proposal. It was discussed, formally reviewed and
>> 

Re: [swift-evolution] Revisiting SE-0110

[Vladimir.S via swift-evolution]

On 01.06.2017 19:31, Tommaso Piazza wrote:

Dear all,

I made a comparison of Swift's 4 lack of tuple unsplatting, here is how it stands in 
comparison with other languages


https://gist.github.com/blender/53f9568617654c38a219dd4a8353d935



Thank you! Very useful information. And also I really like the opinion of 
@AliSoftware in comments for this article.


I'd suggest to add this variant to Swift section in your article:

let eighteenOrMore = ["Tom" : 33, "Rebecca" : 17, "Siri" : 5].filter {
(arg: (name: String, age: Int)) in arg.age >= 18 }

(I believe it is better that 2 others Swift variants.)

It seems for me that we need to allow some special syntax for *explicit* tuple 
destructuring in closures to make all happy.


FWIW These suggestions are my favorite:

1. Just allow type inference for tuple's destructured variables in this 
position:

.filter { (arg: (name, age)) in arg.age >= 18 }


2. (1) + allow underscore for tuple argument name:

.filter { (_: (name, age)) in age >= 18 }


3. (2) + allow to omit parenthesis (probably only in case of just one tuple 
argument)

.filter { _: (name, age) in age >= 18 }


4. Use pattern matching syntax:

.filter { case let (name, age) in age >= 18 }

(looks similar as allowed today: if case let (name, age) = x { print(name, age) 
}  )


5. Use two pairs of parenthesis :

.filter { ((name, age)) in age >= 18 }

Btw, about the 5th variant. If took what is allowed today:
.filter { (arg: (name: String, age: Int)) in arg.age >= 18 }
, and allow type inference for tuple part arguments, we'll have this:
.filter { (arg: (name, age)) in arg.age >= 18 }
, and if additionally allow skipping of tuple argument declaration we'll have:
.filter { ((name, age)) in arg.age >= 18 }
I.e. two pairs for parenthesis for tuple destructuring, and such syntax is similar to 
the type this closure should have : ((String, Int)) -> Bool







On Thursday, June 1, 2017 12:25 PM, Vladimir.S via swift-evolution 
 wrote:



On 01.06.2017 0:42, John McCall wrote:
 >> On May 31, 2017, at 2:02 PM, Stephen Celis > wrote:

 >>> On May 28, 2017, at 7:04 PM, John McCall via swift-evolution
 >>> > wrote:
 >>>
 >>> Yes, I agree.  We need to add back tuple destructuring in closure parameter
 >>> lists because this is a serious usability regression.  If we're reluctant 
to
 >>> just "do the right thing" to handle the ambiguity of (a,b), we should at 
least
 >>> allow it via unambiguous syntax like ((a,b)).  I do think that we should 
just
 >>> "do the right thing", however, with my biggest concern being whether 
there's
 >>> any reasonable way to achieve that in 4.0.
 >>
 >> Closure parameter lists are unfortunately only half of the equation here. 
This
 >> change also regresses the usability of point-free expression.
 >
 > The consequences for point-free style were expected and cannot really be
 > eliminated without substantially weakening SE-0110.  Closure convenience 
seems to
 > me to be a much more serious regression.

John, do you also want to say "and without weakening SE-0066"? Because, if I
understand correctly, in this case:

   func add(_ x: Int, _ y: Int) -> Int {
 return x + y
   }

   zip([1, 2, 3], [4, 5, 6]).map(add)

.. we have a clear function type mismatch situation, when map() expects 
function of
type ((Int, Int))->Int, but function of type (Int,Int)->Int is provided ? So 
probably
the additional 'reason' of the 'problem' in this case is SE-0066, no?
Or I don't understand the SE-0066 correctly..
Do we want to allow implicit conversions between function type ((Int,Int))->Int 
and
(Int,Int)->Int?

Quote from SE-0066:
---
(Int, Int) -> Int// function from Int and Int to Int
((Int, Int)) -> Int  // function from tuple (Int, Int) to Int
---

During this discussion I see a wish of some group of developers to just return 
back
tuple splatting for function/closure arguments, so they can freely send tuple to
function/closure accepting a list of parameters(and probably vise-versa).
Is it worth to follow SE-0066 and SE-0110 as is, i.e. disallow tuple 
deconstructing
and then, as additive change improve the situation with tuple
splatting/deconstructing later with separate big proposal?

Btw, about the SE-0110 proposal. It was discussed, formally reviewed and 
accepted. I
expect that its revision also should be formally proposed/reviewed/accepted to
collect a wide range of opinions and thoughts, and attract the attention of
developers in this list to the subject.


Also, if we revisit SE-0110, will this code be allowed?:

func foo(_ callback: ((Int,Int))->Void) {}
let mycallback = {(x:Int, y:Int)->Void in }
foo(mycallback)

and

func foo(_ callback: (Int,Int)->Void) {}
let mycallback = {(x: (Int, Int))->Void in }
foo(mycallback)

If so, what will be result of this for both cases? :

print(type(of:mycallback)) // (Int,Int)->Void or 

Re: [swift-evolution] Revisiting SE-0110

[John McCall via swift-evolution]

> On Jun 1, 2017, at 3:25 AM, Vladimir.S  wrote:
> 
> On 01.06.2017 0:42, John McCall wrote:
>>> On May 31, 2017, at 2:02 PM, Stephen Celis  wrote:
 On May 28, 2017, at 7:04 PM, John McCall via swift-evolution
  wrote:
 Yes, I agree.  We need to add back tuple destructuring in closure parameter
 lists because this is a serious usability regression.  If we're reluctant 
 to
 just "do the right thing" to handle the ambiguity of (a,b), we should at 
 least
 allow it via unambiguous syntax like ((a,b)).  I do think that we should 
 just
 "do the right thing", however, with my biggest concern being whether 
 there's
 any reasonable way to achieve that in 4.0.
>>> Closure parameter lists are unfortunately only half of the equation here. 
>>> This
>>> change also regresses the usability of point-free expression.
>> The consequences for point-free style were expected and cannot really be
>> eliminated without substantially weakening SE-0110.  Closure convenience 
>> seems to
>> me to be a much more serious regression.
> 
> John, do you also want to say "and without weakening SE-0066"? Because, if I 
> understand correctly, in this case:

No.  SE-0066 was ultimately just a syntax proposal.  SE-0110 clarified the 
intended type-system behavior of function types for both calls and conversions. 
 Removing tuple destructuring from parameter clauses was an incidental 
consequence of that, which in my opinion was pursued out of enthusiasm and 
without adequately understanding the impact on closures.

I understand that there are developers who dislike SE-0110's impact on certain 
kinds of functional programming, but that is a very broad complaint that is 
unlikely to reach consensus or acceptance, especially for Swift 4.  In 
contrast, I think we may be able to gain consensus on a more targeted proposal 
that just re-admits tuple destructuring in closures, assuming we can find an 
acceptable implementation.

John.

> func add(_ x: Int, _ y: Int) -> Int {
>return x + y
>  }
> 
>  zip([1, 2, 3], [4, 5, 6]).map(add)
> 
> .. we have a clear function type mismatch situation, when map() expects 
> function of type ((Int, Int))->Int, but function of type (Int,Int)->Int is 
> provided ? So probably the additional 'reason' of the 'problem' in this case 
> is SE-0066, no?
> Or I don't understand the SE-0066 correctly..
> Do we want to allow implicit conversions between function type 
> ((Int,Int))->Int and (Int,Int)->Int?
> 
> Quote from SE-0066:
> ---
> (Int, Int) -> Int// function from Int and Int to Int
> ((Int, Int)) -> Int  // function from tuple (Int, Int) to Int
> ---
> 
> During this discussion I see a wish of some group of developers to just 
> return back tuple splatting for function/closure arguments, so they can 
> freely send tuple to function/closure accepting a list of parameters(and 
> probably vise-versa).
> Is it worth to follow SE-0066 and SE-0110 as is, i.e. disallow tuple 
> deconstructing and then, as additive change improve the situation with tuple 
> splatting/deconstructing later with separate big proposal?
> 
> Btw, about the SE-0110 proposal. It was discussed, formally reviewed and 
> accepted. I expect that its revision also should be formally 
> proposed/reviewed/accepted to collect a wide range of opinions and thoughts, 
> and attract the attention of developers in this list to the subject.
> 
> 
> Also, if we revisit SE-0110, will this code be allowed?:
> 
> func foo(_ callback: ((Int,Int))->Void) {}
> let mycallback = {(x:Int, y:Int)->Void in }
> foo(mycallback)
> 
> and
> 
> func foo(_ callback: (Int,Int)->Void) {}
> let mycallback = {(x: (Int, Int))->Void in }
> foo(mycallback)
> 
> If so, what will be result of this for both cases? :
> 
> print(type(of:mycallback)) // (Int,Int)->Void or ((Int,Int))->Void
> 
> If allowed, do we want to allow implicit conversion between types 
> (Int,Int)->Void and ((Int,Int))->Void in both directions?  (Hello tuple 
> splatting?)
> 
>> John.
>>> func add(_ x: Int, _ y: Int) -> Int { return x + y }
>>> zip([1, 2, 3], [4, 5, 6]).map(add)
>>> // error: nested tuple parameter '(Int, Int)' of function '(((_.Element,
>>> _.Element)) throws -> _) throws -> [_]' does not support destructuring
>>> This may not be a common pattern in most projects, but we heavily use this 
>>> style
>>> in the Kickstarter app in our functional and FRP code. Definitely not the 
>>> most
>>> common coding pattern, but a very expressive one that we rely on.
>>> Our interim solution is a bunch of overloaded helpers, e.g.:
>>> func tupleUp(_ f: (A, B) -> C) -> ((A, B)) -> C { return }
>>> zip([1, 2, 3], [4, 5, 6]).map(tupleUp(add))
>>> Stephen
>> .

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[John Holdsworth via swift-evolution]

> On 1 Jun 2017, at 17:31, Tommaso Piazza via swift-evolution 
>  wrote:
> 
> >>> On May 28, 2017, at 7:04 PM, John McCall via swift-evolution
> >>> > wrote:
> >>> 
> >>> Yes, I agree.  We need to add back tuple destructuring in closure 
> >>> parameter
> >>> lists because this is a serious usability regression.  If we're reluctant 
> >>> to
> >>> just "do the right thing" to handle the ambiguity of (a,b), we should at 
> >>> least
> >>> allow it via unambiguous syntax like ((a,b)).  I do think that we should 
> >>> just
> >>> "do the right thing", however, with my biggest concern being whether 
> >>> there's
> >>> any reasonable way to achieve that in 4.0.

+1 This seems to be the nub of the solution. It would still be a source 
compatibility breaking change
but only double bracketed syntax can satisfy the anti-ambiguists and the 
single-line-expressivists
and could apply to tuples in general. The current state requiring an 
intermediate variable is terrible.

-John

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Tommaso Piazza via swift-evolution]

Dear all,
I made a comparison of Swift's 4 lack of tuple unsplatting, here is how it 
stands in comparison with other languages
 https://gist.github.com/blender/53f9568617654c38a219dd4a8353d935

 

On Thursday, June 1, 2017 12:25 PM, Vladimir.S via swift-evolution 
 wrote:
 

 On 01.06.2017 0:42, John McCall wrote:
>> On May 31, 2017, at 2:02 PM, Stephen Celis  wrote:
>>> On May 28, 2017, at 7:04 PM, John McCall via swift-evolution
>>>  wrote:
>>> 
>>> Yes, I agree.  We need to add back tuple destructuring in closure parameter
>>> lists because this is a serious usability regression.  If we're reluctant to
>>> just "do the right thing" to handle the ambiguity of (a,b), we should at 
>>> least
>>> allow it via unambiguous syntax like ((a,b)).  I do think that we should 
>>> just
>>> "do the right thing", however, with my biggest concern being whether there's
>>> any reasonable way to achieve that in 4.0.
>> 
>> Closure parameter lists are unfortunately only half of the equation here. 
>> This
>> change also regresses the usability of point-free expression.
> 
> The consequences for point-free style were expected and cannot really be
> eliminated without substantially weakening SE-0110.  Closure convenience 
> seems to
> me to be a much more serious regression.

John, do you also want to say "and without weakening SE-0066"? Because, if I 
understand correctly, in this case:

  func add(_ x: Int, _ y: Int) -> Int {
    return x + y
  }

  zip([1, 2, 3], [4, 5, 6]).map(add)

.. we have a clear function type mismatch situation, when map() expects 
function of 
type ((Int, Int))->Int, but function of type (Int,Int)->Int is provided ? So 
probably 
the additional 'reason' of the 'problem' in this case is SE-0066, no?
Or I don't understand the SE-0066 correctly..
Do we want to allow implicit conversions between function type ((Int,Int))->Int 
and 
(Int,Int)->Int?

Quote from SE-0066:
---
(Int, Int) -> Int    // function from Int and Int to Int
((Int, Int)) -> Int  // function from tuple (Int, Int) to Int
---

During this discussion I see a wish of some group of developers to just return 
back 
tuple splatting for function/closure arguments, so they can freely send tuple 
to 
function/closure accepting a list of parameters(and probably vise-versa).
Is it worth to follow SE-0066 and SE-0110 as is, i.e. disallow tuple 
deconstructing 
and then, as additive change improve the situation with tuple 
splatting/deconstructing later with separate big proposal?

Btw, about the SE-0110 proposal. It was discussed, formally reviewed and 
accepted. I 
expect that its revision also should be formally proposed/reviewed/accepted to 
collect a wide range of opinions and thoughts, and attract the attention of 
developers in this list to the subject.


Also, if we revisit SE-0110, will this code be allowed?:

func foo(_ callback: ((Int,Int))->Void) {}
let mycallback = {(x:Int, y:Int)->Void in }
foo(mycallback)

and

func foo(_ callback: (Int,Int)->Void) {}
let mycallback = {(x: (Int, Int))->Void in }
foo(mycallback)

If so, what will be result of this for both cases? :

print(type(of:mycallback)) // (Int,Int)->Void or ((Int,Int))->Void

If allowed, do we want to allow implicit conversion between types 
(Int,Int)->Void and 
((Int,Int))->Void in both directions?  (Hello tuple splatting?)

> 
> John.
> 
> 
>> 
>> func add(_ x: Int, _ y: Int) -> Int { return x + y }
>> 
>> zip([1, 2, 3], [4, 5, 6]).map(add)
>> 
>> // error: nested tuple parameter '(Int, Int)' of function '(((_.Element,
>> _.Element)) throws -> _) throws -> [_]' does not support destructuring
>> 
>> This may not be a common pattern in most projects, but we heavily use this 
>> style
>> in the Kickstarter app in our functional and FRP code. Definitely not the 
>> most
>> common coding pattern, but a very expressive one that we rely on.
>> 
>> Our interim solution is a bunch of overloaded helpers, e.g.:
>> 
>> func tupleUp(_ f: (A, B) -> C) -> ((A, B)) -> C { return }
>> 
>> zip([1, 2, 3], [4, 5, 6]).map(tupleUp(add))
>> 
>> Stephen
> 
> .
> 
___
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

Re: [swift-evolution] Revisiting SE-0110

[Tony Parker via swift-evolution]

> On May 31, 2017, at 3:53 PM, John McCall  wrote:
> 
>> On May 31, 2017, at 3:42 PM, Tony Parker > > wrote:
>>> On May 31, 2017, at 1:16 PM, John McCall via swift-evolution 
>>> > wrote:
>>> 
 On May 30, 2017, at 7:41 AM, Nevin Brackett-Rozinsky via swift-evolution 
 > wrote:
 On Mon, May 29, 2017 at 10:47 PM, Robert Bennett > wrote:
 I think the goal of SE 0110 and to a lesser extent 0066 was to disallow 
 this level of intelligence in the compiler.
 
 Interesting.
 
 I happen to think that the goal of SE–110 
 
  was to make Swift's type system “properly distinguish between functions 
 that take one tuple argument, and functions that take multiple arguments.” 
 Nowhere does that proposal discuss tuple destructuring, and nowhere does 
 it discuss optional parentheses around closure parameter lists.
 
 I might go so far as to say that any commits which *do* affect those 
 things, cannot possibly be correct implementations of the accepted 
 proposal SE–110, because SE–110 did not describe any changes there.
 
 With SE–66 
 
  the case is even more clearcut: that proposal explicitly addresses the 
 question, “Should we require parentheses in closure expression parameter 
 lists?“ and answers it in the negative. The core team’s notes 
 
  on accepting also specify, “The core team did not feel that this proposal 
 needed to include required parentheses within closures, which have their 
 own fairly specific grammar.”
 
 
 While technically feasible, it's not desirable to overload parentheses in 
 this manner.
 
 I strongly disagree. Language features are desirable exactly to the extent 
 that they make life better for developers.
 
 Moreover, parentheses are *already* optional in closure parameter lists. 
 Making them mandatory would be source-breaking for no benefit to 
 programmers. Plus having to write double-parentheses in “dict.map{ ((key, 
 value)) in … }” would be needlessly annoying.
>>> 
>>> This is basically my perspective.  There are language features where we've 
>>> made an intentional decision to require the user to write things in a 
>>> specific way.  Closure parameter lists are not one of them; we've already 
>>> committed to using a very permissive and flexible grammar.  Perhaps that 
>>> was a mistake, but it's a mistake we've made and cannot reasonably undo, 
>>> notwithstanding the proposals that are basically "we should ban 
>>> such-and-such style that, coincidentally, I happen not to use."  In the 
>>> long term, I feel confident that we can deliver an implementation that 
>>> resolves the multiple-parameter vs. tuple-decomposition ambiguity without 
>>> making any significant compromises, but I'm not sure whether we can 
>>> reasonably achieve that in 4.0.
>>> 
>>> John.
>> 
>> As far as I can tell, right now is the earliest possible opportunity for us 
>> to get real feedback on the impact of this proposal.
>> 
>> Therefore, it seems unfortunate that the apparent response is that it is 
>> already too late to fix the problem. Or, perhaps I am misunderstanding?
> 
> I am not trying to say that it is too late to fix the problem.  Some 
> solutions might be off the table, but we need to investigate what we can do.
> 
> John.

Ok, great, I’m glad to hear that.

Thanks,
- Tony

> 
>> 
>> - Tony
>> 
>>> 
 
 In my view there have been far too many calls for making Swift 
 “consistent” in ways that actually make it less enjoyable to use. That is 
 the opposite of “Swifty”, and we should instead prioritize convenience for 
 users above rigid consistency of implementation.
 
 In the case at hand, with Dictionary.map, the vast majority of the time 
 the user doesn’t actually care whether the closure takes two arguments or 
 a single 2-tuple argument. They just know that it takes a key and a value, 
 and they want to be able to write “dict.map{ (key, value) in … }”.
 
 Sure, the closure *does* take a 2-tuple, and it does not take two 
 arguments, but the programmer *using* it shouldn’t have to bother about 
 that distinction most of the time. They just want to assign the key to one 
 identifier and the value to another. If they try to write “key, value” 
 without any parentheses the compiler will complain and they’ll add the 
 

Re: [swift-evolution] Revisiting SE-0110

[John McCall via swift-evolution]

> On May 31, 2017, at 3:42 PM, Tony Parker  wrote:
>> On May 31, 2017, at 1:16 PM, John McCall via swift-evolution 
>> > wrote:
>> 
>>> On May 30, 2017, at 7:41 AM, Nevin Brackett-Rozinsky via swift-evolution 
>>> > wrote:
>>> On Mon, May 29, 2017 at 10:47 PM, Robert Bennett >> > wrote:
>>> I think the goal of SE 0110 and to a lesser extent 0066 was to disallow 
>>> this level of intelligence in the compiler.
>>> 
>>> Interesting.
>>> 
>>> I happen to think that the goal of SE–110 
>>> 
>>>  was to make Swift's type system “properly distinguish between functions 
>>> that take one tuple argument, and functions that take multiple arguments.” 
>>> Nowhere does that proposal discuss tuple destructuring, and nowhere does it 
>>> discuss optional parentheses around closure parameter lists.
>>> 
>>> I might go so far as to say that any commits which *do* affect those 
>>> things, cannot possibly be correct implementations of the accepted proposal 
>>> SE–110, because SE–110 did not describe any changes there.
>>> 
>>> With SE–66 
>>> 
>>>  the case is even more clearcut: that proposal explicitly addresses the 
>>> question, “Should we require parentheses in closure expression parameter 
>>> lists?“ and answers it in the negative. The core team’s notes 
>>> 
>>>  on accepting also specify, “The core team did not feel that this proposal 
>>> needed to include required parentheses within closures, which have their 
>>> own fairly specific grammar.”
>>> 
>>> 
>>> While technically feasible, it's not desirable to overload parentheses in 
>>> this manner.
>>> 
>>> I strongly disagree. Language features are desirable exactly to the extent 
>>> that they make life better for developers.
>>> 
>>> Moreover, parentheses are *already* optional in closure parameter lists. 
>>> Making them mandatory would be source-breaking for no benefit to 
>>> programmers. Plus having to write double-parentheses in “dict.map{ ((key, 
>>> value)) in … }” would be needlessly annoying.
>> 
>> This is basically my perspective.  There are language features where we've 
>> made an intentional decision to require the user to write things in a 
>> specific way.  Closure parameter lists are not one of them; we've already 
>> committed to using a very permissive and flexible grammar.  Perhaps that was 
>> a mistake, but it's a mistake we've made and cannot reasonably undo, 
>> notwithstanding the proposals that are basically "we should ban 
>> such-and-such style that, coincidentally, I happen not to use."  In the long 
>> term, I feel confident that we can deliver an implementation that resolves 
>> the multiple-parameter vs. tuple-decomposition ambiguity without making any 
>> significant compromises, but I'm not sure whether we can reasonably achieve 
>> that in 4.0.
>> 
>> John.
> 
> As far as I can tell, right now is the earliest possible opportunity for us 
> to get real feedback on the impact of this proposal.
> 
> Therefore, it seems unfortunate that the apparent response is that it is 
> already too late to fix the problem. Or, perhaps I am misunderstanding?

I am not trying to say that it is too late to fix the problem.  Some solutions 
might be off the table, but we need to investigate what we can do.

John.

> 
> - Tony
> 
>> 
>>> 
>>> In my view there have been far too many calls for making Swift “consistent” 
>>> in ways that actually make it less enjoyable to use. That is the opposite 
>>> of “Swifty”, and we should instead prioritize convenience for users above 
>>> rigid consistency of implementation.
>>> 
>>> In the case at hand, with Dictionary.map, the vast majority of the time the 
>>> user doesn’t actually care whether the closure takes two arguments or a 
>>> single 2-tuple argument. They just know that it takes a key and a value, 
>>> and they want to be able to write “dict.map{ (key, value) in … }”.
>>> 
>>> Sure, the closure *does* take a 2-tuple, and it does not take two 
>>> arguments, but the programmer *using* it shouldn’t have to bother about 
>>> that distinction most of the time. They just want to assign the key to one 
>>> identifier and the value to another. If they try to write “key, value” 
>>> without any parentheses the compiler will complain and they’ll add the 
>>> parens. But if the compiler demands a *second* set of parentheses, that 
>>> will just seem ridiculous.
>>> 
>>> Nevin
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 

Re: [swift-evolution] Revisiting SE-0110

[Tony Parker via swift-evolution]

> On May 31, 2017, at 1:16 PM, John McCall via swift-evolution 
>  wrote:
> 
>> On May 30, 2017, at 7:41 AM, Nevin Brackett-Rozinsky via swift-evolution 
>> > wrote:
>> On Mon, May 29, 2017 at 10:47 PM, Robert Bennett > > wrote:
>> I think the goal of SE 0110 and to a lesser extent 0066 was to disallow this 
>> level of intelligence in the compiler.
>> 
>> Interesting.
>> 
>> I happen to think that the goal of SE–110 
>> 
>>  was to make Swift's type system “properly distinguish between functions 
>> that take one tuple argument, and functions that take multiple arguments.” 
>> Nowhere does that proposal discuss tuple destructuring, and nowhere does it 
>> discuss optional parentheses around closure parameter lists.
>> 
>> I might go so far as to say that any commits which *do* affect those things, 
>> cannot possibly be correct implementations of the accepted proposal SE–110, 
>> because SE–110 did not describe any changes there.
>> 
>> With SE–66 
>> 
>>  the case is even more clearcut: that proposal explicitly addresses the 
>> question, “Should we require parentheses in closure expression parameter 
>> lists?“ and answers it in the negative. The core team’s notes 
>> 
>>  on accepting also specify, “The core team did not feel that this proposal 
>> needed to include required parentheses within closures, which have their own 
>> fairly specific grammar.”
>> 
>> 
>> While technically feasible, it's not desirable to overload parentheses in 
>> this manner.
>> 
>> I strongly disagree. Language features are desirable exactly to the extent 
>> that they make life better for developers.
>> 
>> Moreover, parentheses are *already* optional in closure parameter lists. 
>> Making them mandatory would be source-breaking for no benefit to 
>> programmers. Plus having to write double-parentheses in “dict.map{ ((key, 
>> value)) in … }” would be needlessly annoying.
> 
> This is basically my perspective.  There are language features where we've 
> made an intentional decision to require the user to write things in a 
> specific way.  Closure parameter lists are not one of them; we've already 
> committed to using a very permissive and flexible grammar.  Perhaps that was 
> a mistake, but it's a mistake we've made and cannot reasonably undo, 
> notwithstanding the proposals that are basically "we should ban such-and-such 
> style that, coincidentally, I happen not to use."  In the long term, I feel 
> confident that we can deliver an implementation that resolves the 
> multiple-parameter vs. tuple-decomposition ambiguity without making any 
> significant compromises, but I'm not sure whether we can reasonably achieve 
> that in 4.0.
> 
> John.

As far as I can tell, right now is the earliest possible opportunity for us to 
get real feedback on the impact of this proposal.

Therefore, it seems unfortunate that the apparent response is that it is 
already too late to fix the problem. Or, perhaps I am misunderstanding?

- Tony

> 
>> 
>> In my view there have been far too many calls for making Swift “consistent” 
>> in ways that actually make it less enjoyable to use. That is the opposite of 
>> “Swifty”, and we should instead prioritize convenience for users above rigid 
>> consistency of implementation.
>> 
>> In the case at hand, with Dictionary.map, the vast majority of the time the 
>> user doesn’t actually care whether the closure takes two arguments or a 
>> single 2-tuple argument. They just know that it takes a key and a value, and 
>> they want to be able to write “dict.map{ (key, value) in … }”.
>> 
>> Sure, the closure *does* take a 2-tuple, and it does not take two arguments, 
>> but the programmer *using* it shouldn’t have to bother about that 
>> distinction most of the time. They just want to assign the key to one 
>> identifier and the value to another. If they try to write “key, value” 
>> without any parentheses the compiler will complain and they’ll add the 
>> parens. But if the compiler demands a *second* set of parentheses, that will 
>> just seem ridiculous.
>> 
>> Nevin
>> ___
>> 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 
> 

Re: [swift-evolution] Revisiting SE-0110

[John McCall via swift-evolution]

> On May 31, 2017, at 2:02 PM, Stephen Celis  wrote:
>> On May 28, 2017, at 7:04 PM, John McCall via swift-evolution 
>>  wrote:
>> 
>> Yes, I agree.  We need to add back tuple destructuring in closure parameter 
>> lists because this is a serious usability regression.  If we're reluctant to 
>> just "do the right thing" to handle the ambiguity of (a,b), we should at 
>> least allow it via unambiguous syntax like ((a,b)).  I do think that we 
>> should just "do the right thing", however, with my biggest concern being 
>> whether there's any reasonable way to achieve that in 4.0.
> 
> Closure parameter lists are unfortunately only half of the equation here. 
> This change also regresses the usability of point-free expression.

The consequences for point-free style were expected and cannot really be 
eliminated without substantially weakening SE-0110.  Closure convenience seems 
to me to be a much more serious regression.

John.


> 
>   func add(_ x: Int, _ y: Int) -> Int {
> return x + y
>   }
> 
>   zip([1, 2, 3], [4, 5, 6]).map(add)
> 
>   // error: nested tuple parameter '(Int, Int)' of function '(((_.Element, 
> _.Element)) throws -> _) throws -> [_]' does not support destructuring
> 
> This may not be a common pattern in most projects, but we heavily use this 
> style in the Kickstarter app in our functional and FRP code. Definitely not 
> the most common coding pattern, but a very expressive one that we rely on.
> 
> Our interim solution is a bunch of overloaded helpers, e.g.:
> 
>   func tupleUp(_ f: (A, B) -> C) -> ((A, B)) -> C {
> return 
>   }
> 
>   zip([1, 2, 3], [4, 5, 6]).map(tupleUp(add))
> 
> Stephen

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Robert Bennett via swift-evolution]

Seeing this makes me rethink the severity of this problem. I wonder if it would 
be worth it to add a starMap function that works like map, but unpacks tuples 
into separate arguments. So dict.map { (key, value) in ... } is still illegal 
but dict.starMap { (key, value) in ... } works like dict.map used to.

On May 31, 2017, at 5:02 PM, Stephen Celis  wrote:

>> On May 28, 2017, at 7:04 PM, John McCall via swift-evolution 
>>  wrote:
>> 
>> Yes, I agree.  We need to add back tuple destructuring in closure parameter 
>> lists because this is a serious usability regression.  If we're reluctant to 
>> just "do the right thing" to handle the ambiguity of (a,b), we should at 
>> least allow it via unambiguous syntax like ((a,b)).  I do think that we 
>> should just "do the right thing", however, with my biggest concern being 
>> whether there's any reasonable way to achieve that in 4.0.
> 
> Closure parameter lists are unfortunately only half of the equation here. 
> This change also regresses the usability of point-free expression.
> 
>   func add(_ x: Int, _ y: Int) -> Int {
> return x + y
>   }
> 
>   zip([1, 2, 3], [4, 5, 6]).map(add)
> 
>   // error: nested tuple parameter '(Int, Int)' of function '(((_.Element, 
> _.Element)) throws -> _) throws -> [_]' does not support destructuring
> 
> This may not be a common pattern in most projects, but we heavily use this 
> style in the Kickstarter app in our functional and FRP code. Definitely not 
> the most common coding pattern, but a very expressive one that we rely on.
> 
> Our interim solution is a bunch of overloaded helpers, e.g.:
> 
>   func tupleUp(_ f: (A, B) -> C) -> ((A, B)) -> C {
> return 
>   }
> 
>   zip([1, 2, 3], [4, 5, 6]).map(tupleUp(add))
> 
> Stephen
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution