Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

[Xiaodi Wu via swift-evolution]

On Fri, May 5, 2017 at 12:54 AM, David Hart  wrote:

>
> On 5 May 2017, at 07:17, Robert Widmann via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On the contrary, this is precisely what it means to deprecate tuple
> shuffles.  You can’t map common parlance onto this term; the proposal and
> the Twitter thread weren’t merely about reordering arguments.
>
> but it is entirely another ballgame to remove labels from tuple patterns
> altogether.
>
>
> It’s really not.  Let me demonstrate:
>
> To be clear, are you proposing the prohibition of *adding or removing*
>> labels as well? A previous discussion on tuple shuffling on this list saw
>> consensus that assigning a value of type (label1: T, label2: U) to a
>> variable of type (T, U) and vice versa should absolutely be supported,
>> whether or not reordering is permitted.
>
>
> I am not proposing any changes to switching parameter labels through
> well-typed re-assignments.  This is absolutely still going to be allowed:
>
> var z : (Int, Int) = (0, 0)
> var w : (x : Int, y : Int) = (5, 10)
> z = w
> w = z
>
> This is modeled internally with a tuple shuffle, but not the kind of
> shuffle I’m interested in banning.  It’s a far simpler kind of
>
> And how about *restating* existing labels without any adding or removing?
>> To be clear:
>>
>> ```
>> let (partialValue: v, overflow: o) = 42.addingReportingOverflow(42)
>> ```
>>
>> ...involves absolutely no changes in labels whatsoever. The return type
>> is (partialValue: Int, overflow: ArithmeticOverflow).
>>
>
> That, however, is a kind of shuffle I intend to deprecate here.  This kind
> of pattern is subject to the “arcane syntax” part of the proposal.
>
>
>> Either one of these scenarios is commonly used, and it is astonishing to
>> me that they would be eliminated.
>
>
> Do you have proof of that claim? I have never seen the relevant kinds of
> tuple shuffle used before, and I doubt you have either before today.
>
>
> For what it's worth, I thought I knew Swift inside out and I had never
> seen or used the syntax your are proposing to ban, so I'm all for it.
>

If you google "Swift tuple destructuring," it's demonstrated in the third
link you can click on. The article is even titled "best practices":

https://github.com/terhechte/appventure-blog/blob/master/resources/posts/2015-07-19-tuples-swift-advanced-usage-best-practices.org

~Robert Widmann
>
> On May 5, 2017, at 12:53 AM, Xiaodi Wu  wrote:
>
> Ah, I see from your proposed grammar update: you're proposing to prohibit
> the use of labels entirely in a tuple pattern.
>
> This is much more than just prohibiting tuple shuffling, and I'm rather
> disappointed that you described such a dramatic change using a corner case.
> There are very good reasons why someone finds 'let (y: x, x: y) = (x: 1, y:
> 2)' confusing and would support its removal, but it is entirely another
> ballgame to remove labels from tuple patterns altogether.
>
>
> On Thu, May 4, 2017 at 23:47 Xiaodi Wu  wrote:
>
>> Now I'm confused. The ordinary meaning of the word "shuffle" is not
>> changing but rather reordering, and all of your examples are of reordering.
>>
>> To be clear, are you proposing the prohibition of *adding or removing*
>> labels as well? A previous discussion on tuple shuffling on this list saw
>> consensus that assigning a value of type (label1: T, label2: U) to a
>> variable of type (T, U) and vice versa should absolutely be supported,
>> whether or not reordering is permitted.
>>
>> And how about *restating* existing labels without any adding or removing?
>> To be clear:
>>
>> ```
>> let (partialValue: v, overflow: o) = 42.addingReportingOverflow(42)
>> ```
>>
>> ...involves absolutely no changes in labels whatsoever. The return type
>> is (partialValue: Int, overflow: ArithmeticOverflow).
>>
>> Either one of these scenarios is commonly used, and it is astonishing to
>> me that they would be eliminated.
>>
>> On Thu, May 4, 2017 at 23:28 Robert Widmann 
>> wrote:
>>
>>> That doesn't involve a parameter *reordering*, but because it changes
>>> argument labels it's a shuffle.
>>>
>>> ~Robert Widmann
>>>
>>> 2017/05/05 0:16、Xiaodi Wu  のメッセージ:
>>>
>>> Robert,
>>>
>>> As I mentioned on Twitter, getting rid of tuple shuffles would not cure
>>> your example, which does not involve a shuffle. Unless you're proposing to
>>> disallow the use of labels during destructuring entirely, which I would
>>> think to be very much unacceptable. Example:
>>>
>>> ```
>>> let (partialValue: v, overflow: o) = 42.addingReportingOverflow(42)
>>> ```
>>>
>>> This involves no shuffling and should absolutely remain allowed.
>>>
>>>
>>> On Thu, May 4, 2017 at 21:15 Robert Widmann via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 Hi all,

 So sorry that this proposal comes so late in the game, but I feel it’s
 too important not to bring it to the 

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

[David Hart via swift-evolution]

> On 5 May 2017, at 07:17, Robert Widmann via swift-evolution 
>  wrote:
> 
> On the contrary, this is precisely what it means to deprecate tuple shuffles. 
>  You can’t map common parlance onto this term; the proposal and the Twitter 
> thread weren’t merely about reordering arguments.
> 
>> but it is entirely another ballgame to remove labels from tuple patterns 
>> altogether.
> 
> It’s really not.  Let me demonstrate:
> 
>>> To be clear, are you proposing the prohibition of *adding or removing* 
>>> labels as well? A previous discussion on tuple shuffling on this list saw 
>>> consensus that assigning a value of type (label1: T, label2: U) to a 
>>> variable of type (T, U) and vice versa should absolutely be supported, 
>>> whether or not reordering is permitted.
> 
> I am not proposing any changes to switching parameter labels through 
> well-typed re-assignments.  This is absolutely still going to be allowed:
> 
> var z : (Int, Int) = (0, 0)
> var w : (x : Int, y : Int) = (5, 10)
> z = w
> w = z
> 
> This is modeled internally with a tuple shuffle, but not the kind of shuffle 
> I’m interested in banning.  It’s a far simpler kind of 
> 
>>> And how about *restating* existing labels without any adding or removing? 
>>> To be clear:
>>> 
>>> ```
>>> let (partialValue: v, overflow: o) = 42.addingReportingOverflow(42)
>>> ```
>>> 
>>> ...involves absolutely no changes in labels whatsoever. The return type is 
>>> (partialValue: Int, overflow: ArithmeticOverflow).
> 
> That, however, is a kind of shuffle I intend to deprecate here.  This kind of 
> pattern is subject to the “arcane syntax” part of the proposal.
> 
>>> 
>>> Either one of these scenarios is commonly used, and it is astonishing to me 
>>> that they would be eliminated.
> 
> Do you have proof of that claim? I have never seen the relevant kinds of 
> tuple shuffle used before, and I doubt you have either before today.

For what it's worth, I thought I knew Swift inside out and I had never seen or 
used the syntax your are proposing to ban, so I'm all for it.

> ~Robert Widmann
> 
>> On May 5, 2017, at 12:53 AM, Xiaodi Wu  wrote:
>> 
>> Ah, I see from your proposed grammar update: you're proposing to prohibit 
>> the use of labels entirely in a tuple pattern.
>> 
>> This is much more than just prohibiting tuple shuffling, and I'm rather 
>> disappointed that you described such a dramatic change using a corner case. 
>> There are very good reasons why someone finds 'let (y: x, x: y) = (x: 1, y: 
>> 2)' confusing and would support its removal, but it is entirely another 
>> ballgame to remove labels from tuple patterns altogether.
>> 
>> 
>>> On Thu, May 4, 2017 at 23:47 Xiaodi Wu  wrote:
>>> Now I'm confused. The ordinary meaning of the word "shuffle" is not 
>>> changing but rather reordering, and all of your examples are of reordering.
>>> 
>>> To be clear, are you proposing the prohibition of *adding or removing* 
>>> labels as well? A previous discussion on tuple shuffling on this list saw 
>>> consensus that assigning a value of type (label1: T, label2: U) to a 
>>> variable of type (T, U) and vice versa should absolutely be supported, 
>>> whether or not reordering is permitted.
>>> 
>>> And how about *restating* existing labels without any adding or removing? 
>>> To be clear:
>>> 
>>> ```
>>> let (partialValue: v, overflow: o) = 42.addingReportingOverflow(42)
>>> ```
>>> 
>>> ...involves absolutely no changes in labels whatsoever. The return type is 
>>> (partialValue: Int, overflow: ArithmeticOverflow).
>>> 
>>> Either one of these scenarios is commonly used, and it is astonishing to me 
>>> that they would be eliminated.
>>> 
 On Thu, May 4, 2017 at 23:28 Robert Widmann  
 wrote:
 That doesn't involve a parameter reordering, but because it changes 
 argument labels it's a shuffle.
 
 ~Robert Widmann
 
 2017/05/05 0:16、Xiaodi Wu  のメッセージ:
 
> Robert,
> 
> As I mentioned on Twitter, getting rid of tuple shuffles would not cure 
> your example, which does not involve a shuffle. Unless you're proposing 
> to disallow the use of labels during destructuring entirely, which I 
> would think to be very much unacceptable. Example:
> 
> ```
> let (partialValue: v, overflow: o) = 42.addingReportingOverflow(42)
> ```
> 
> This involves no shuffling and should absolutely remain allowed.
> 
> 
>> On Thu, May 4, 2017 at 21:15 Robert Widmann via swift-evolution 
>>  wrote:
>> Hi all,
>> 
>> So sorry that this proposal comes so late in the game, but I feel it’s 
>> too important not to bring it to the attention of the community now.  
>> Attached is a proposal to deprecate a language feature many of you will 
>> probably have never had the chance to use: Tuple Shuffles.  I’ve 
>> 

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

[Xiaodi Wu via swift-evolution]

On Fri, May 5, 2017 at 12:52 AM, Adrian Zubarev <
adrian.zuba...@devandartist.com> wrote:

> Eliminating all labels would mean that even the first example from my last
> post will be banned.
>
No, not eliminating all labels from tuples, but from tuple _patterns_.


> Is there any difference from labels in tuple types and labels in tuples
> themselves?
>
> Personally I would not support the removal of labels from tuple types,
> because it’s a very useful feature that replaces indexed access like
> myTuple.1 to a more readable counterpart myTuple.somethingSpecial.
>
> Am I still missing something out?
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 5. Mai 2017 um 07:43:49, Xiaodi Wu (xiaodi...@gmail.com) schrieb:
>
> On Fri, May 5, 2017 at 12:42 AM, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Okay now I see where this is going. So basically you want to mirror the
>> behavior of function parameters into tuples.
>>
>> You might want to be a little bit more explicit on types in your proposal
>> to better understand the so called ‘tuple shuffle’.
>>
>> let a: (x: Int, y: Int) = (x: 1, y: 2)
>> var b: (y: Int, x: Int) = a
>> a.x == b.x
>> a.y == b.y
>>
>> Label swap (tuple shuffle) while destructuring:
>>
>> let tuple: (first: Int, second: (x: Int, y: Int)) = (first: 0, second: (x: 
>> 1, y: 2))
>>
>> let (first: a, second: (x: b, y: c)): (first: Int, second: (x: Int, y: Int)) 
>> = tuple // fine, unaffected
>>
>> let (second: (x: b, y: c), first: a): (second: (x: Int, y: Int), first: Int) 
>> = tuple // shuffle => error
>>
>>
> No, I thought this was what Robert was proposing, but he is proposing the
> elimination of all labels in tuple patterns. Your second example would be
> banned.
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

[Adrian Zubarev via swift-evolution]

Eliminating all labels would mean that even the first example from my last post 
will be banned.

Is there any difference from labels in tuple types and labels in tuples 
themselves?

Personally I would not support the removal of labels from tuple types, because 
it’s a very useful feature that replaces indexed access like myTuple.1 to a 
more readable counterpart myTuple.somethingSpecial.

Am I still missing something out?



-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 07:43:49, Xiaodi Wu (xiaodi...@gmail.com) schrieb:

On Fri, May 5, 2017 at 12:42 AM, Adrian Zubarev via swift-evolution 
 wrote:
Okay now I see where this is going. So basically you want to mirror the 
behavior of function parameters into tuples.

You might want to be a little bit more explicit on types in your proposal to 
better understand the so called ‘tuple shuffle’.

let a: (x: Int, y: Int) = (x: 1, y: 2)
var b: (y: Int, x: Int) = a
a.x == b.x
a.y == b.y
Label swap (tuple shuffle) while destructuring:

let tuple: (first: Int, second: (x: Int, y: Int)) = (first: 0, second: (x: 1, 
y: 2))

let (first: a, second: (x: b, y: c)): (first: Int, second: (x: Int, y: Int)) = 
tuple // fine, unaffected

let (second: (x: b, y: c), first: a): (second: (x: Int, y: Int), first: Int) = 
tuple // shuffle => error

No, I thought this was what Robert was proposing, but he is proposing the 
elimination of all labels in tuple patterns. Your second example would be 
banned.

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

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

[Xiaodi Wu via swift-evolution]

On Fri, May 5, 2017 at 12:42 AM, Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> Okay now I see where this is going. So basically you want to mirror the
> behavior of function parameters into tuples.
>
> You might want to be a little bit more explicit on types in your proposal
> to better understand the so called ‘tuple shuffle’.
>
> let a: (x: Int, y: Int) = (x: 1, y: 2)
> var b: (y: Int, x: Int) = a
> a.x == b.x
> a.y == b.y
>
> Label swap (tuple shuffle) while destructuring:
>
> let tuple: (first: Int, second: (x: Int, y: Int)) = (first: 0, second: (x: 1, 
> y: 2))
>
> let (first: a, second: (x: b, y: c)): (first: Int, second: (x: Int, y: Int)) 
> = tuple // fine, unaffected
>
> let (second: (x: b, y: c), first: a): (second: (x: Int, y: Int), first: Int) 
> = tuple // shuffle => error
>
>
No, I thought this was what Robert was proposing, but he is proposing the
elimination of all labels in tuple patterns. Your second example would be
banned.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

[Xiaodi Wu via swift-evolution]

On Fri, May 5, 2017 at 00:17 Robert Widmann 
wrote:

> On the contrary, this is precisely what it means to deprecate tuple
> shuffles.  You can’t map common parlance onto this term; the proposal and
> the Twitter thread weren’t merely about reordering arguments.
>

Let's be clear: _all_ of your examples of "shuffles" in the proposal
involve reordering. You defined a tuple shuffle as such: "an undocumented
feature of Swift in which one can re-order the indices of a tuple" If
you intend to propose a broader change, it is grossly misleading to write
it up in this way.

but it is entirely another ballgame to remove labels from tuple patterns
> altogether.
>
>
> It’s really not.  Let me demonstrate:
>
> To be clear, are you proposing the prohibition of *adding or removing*
>> labels as well? A previous discussion on tuple shuffling on this list saw
>> consensus that assigning a value of type (label1: T, label2: U) to a
>> variable of type (T, U) and vice versa should absolutely be supported,
>> whether or not reordering is permitted.
>
>
> I am not proposing any changes to switching parameter labels through
> well-typed re-assignments.  This is absolutely still going to be allowed:
>
> var z : (Int, Int) = (0, 0)
> var w : (x : Int, y : Int) = (5, 10)
> z = w
> w = z
>
> This is modeled internally with a tuple shuffle, but not the kind of
> shuffle I’m interested in banning.  It’s a far simpler kind of
>

What is your proposed behavior for the following code?

```
let x: (r: Int, g: Int, b: Int, a: Int) = (255, 255, 255, 0)
let y: (a: Int, r: Int, g: Int, b: Int) = x

print(y.a) // currently, prints "0"
```

Either you are proposing only to remove labels from tuple patterns, which
does not at all prohibit reordering, or you are proposing to prohibit
reordering, in which case this code has an error--or it doesn't and you've
instead _silently_ changed the behavior of existing code. One can live with
warnings and even errors, but a silent change to existing code is the stuff
of nightmares, and I would be strongly opposed to that.


>
> And how about *restating* existing labels without any adding or removing?
>> To be clear:
>>
>> ```
>> let (partialValue: v, overflow: o) = 42.addingReportingOverflow(42)
>> ```
>>
>> ...involves absolutely no changes in labels whatsoever. The return type
>> is (partialValue: Int, overflow: ArithmeticOverflow).
>>
>
> That, however, is a kind of shuffle I intend to deprecate here.  This kind
> of pattern is subject to the “arcane syntax” part of the proposal.
>
>
>> Either one of these scenarios is commonly used, and it is astonishing to
>> me that they would be eliminated.
>
>
> Do you have proof of that claim? I have never seen the relevant kinds of
> tuple shuffle used before, and I doubt you have either before today.
>

Huh? I use it pervasively. Currently, writing out labels during
destructuring guarantees that, even if I've incorrectly memorized the order
of the values in a tuple, the tuple is still destructured as I expect. And
if reordering were not a feature of Swift, I would still write out these
labels. In that case, it would be a static assertion that destructuring is
happening in the expected order. That is, if I try to destructure a tuple
of type (r: Int, g: Int, b: Int, a: Int) and accidentally write 'let (a:
alpha, r: _, g: green, b: _) = ...', I'd get an error and find my mistake
at compile time.

The whole point of having labels in the first place is clarity at the point
of use. Just as SE-0111 will need revision because it removed a key
documentation use for argument labels, forbidding labels in tuple patterns
would make the same mistake for tuples.



> ~Robert Widmann
>
> On May 5, 2017, at 12:53 AM, Xiaodi Wu  wrote:
>
> Ah, I see from your proposed grammar update: you're proposing to prohibit
> the use of labels entirely in a tuple pattern.
>
> This is much more than just prohibiting tuple shuffling, and I'm rather
> disappointed that you described such a dramatic change using a corner case.
> There are very good reasons why someone finds 'let (y: x, x: y) = (x: 1, y:
> 2)' confusing and would support its removal, but it is entirely another
> ballgame to remove labels from tuple patterns altogether.
>
>
> On Thu, May 4, 2017 at 23:47 Xiaodi Wu  wrote:
>
>> Now I'm confused. The ordinary meaning of the word "shuffle" is not
>> changing but rather reordering, and all of your examples are of reordering.
>>
>> To be clear, are you proposing the prohibition of *adding or removing*
>> labels as well? A previous discussion on tuple shuffling on this list saw
>> consensus that assigning a value of type (label1: T, label2: U) to a
>> variable of type (T, U) and vice versa should absolutely be supported,
>> whether or not reordering is permitted.
>>
>> And how about *restating* existing labels without any adding or removing?
>> To be clear:
>>
>> ```
>> let (partialValue: v, overflow: o) = 

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

[Adrian Zubarev via swift-evolution]

Okay now I see where this is going. So basically you want to mirror the 
behavior of function parameters into tuples.

You might want to be a little bit more explicit on types in your proposal to 
better understand the so called ‘tuple shuffle’.

let a: (x: Int, y: Int) = (x: 1, y: 2)
var b: (y: Int, x: Int) = a
a.x == b.x
a.y == b.y
Label swap (tuple shuffle) while destructuring:

let tuple: (first: Int, second: (x: Int, y: Int)) = (first: 0, second: (x: 1, 
y: 2))

let (first: a, second: (x: b, y: c)): (first: Int, second: (x: Int, y: Int)) = 
tuple // fine, unaffected

let (second: (x: b, y: c), first: a): (second: (x: Int, y: Int), first: Int) = 
tuple // shuffle => error


-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 07:18:37, Robert Widmann (devteam.cod...@gmail.com) schrieb:

None of those are affected.  See the note in the proposal.

~Robert Widmann

On May 5, 2017, at 1:16 AM, Adrian Zubarev  
wrote:

Hi Robert,

I’m trying to understand the impact of your proposal and the feature you want 
to remove from the language. Could you describe a little more on how if ever 
this affects tuple destructuring? 

var (a, b, c) = (0, "", 0)

(a, b) = (42, "Hello Swift")

(a = 42, b = "Hello Swift")

var (x, y) = (0, 42)

(x, y) = (y, x) // swap without a temporary value



-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 04:15:12, Robert Widmann via swift-evolution 
(swift-evolution@swift.org) schrieb:

Hi all,

So sorry that this proposal comes so late in the game, but I feel it’s too 
important not to bring it to the attention of the community now.  Attached is a 
proposal to deprecate a language feature many of you will probably have never 
had the chance to use: Tuple Shuffles.  I’ve attached a copy of the first draft 
of the proposal below, but the latest copy can be read on Github.

Thanks!

~Robert Widmann

Deprecate Tuple Shuffles
Proposal: SE-
Authors: Robert Widmann
Review Manager: TBD
Status: Awaiting review
Introduction

This proposal seeks the deprecation of a little-known feature of Swift called a 
"Tuple Shuffle".

Motivation

A tuple-shuffle is an undocumented feature of Swift in which one can re-order 
the indices of a tuple by writing a pattern that describes a permutation in a 
syntax reminiscent of adding type-annotations to a parameter list:

let a = (x: 1, y: 2)
var b: (y: Int, x: Int)
b = a
It can be used to simultaneously destructure and reorder a tuple:

let tuple = (first: 0, second: (x: 1, y: 2))
let (second: (x: b, y: c), first: a) = tuple
It can also be used to map parameter labels out of order in a call expression:

func foo(_ : (x : Int, y : Int)) {}
foo((y: 5, x: 10)) // Valid
Note that a tuple shuffle is distinct from a re-assignment through a tuple 
pattern. For example, this series of statements will continue to function as 
before:

var x = 5
var y = 10
var z = 15
(z, y, x) = (x, z, y)
Their inclusion in the language complicates every part of the compiler stack, 
uses a syntax that can be confused for type annotations, contradicts the goals 
of earlier SE's (see SE-0060), and makes non-sensical patterns possible in 
surprising places.

Take switch-statements, for example:

switch ((0, 0), 0){   
case (_ : let (y, z), _ : let s): () // We are forbidden from giving these 
patterns names other than "_"  
default: ()   
}
This proposal seeks to deprecate them in Swift 3 compatibility mode and enforce 
that deprecation as a hard error in Swift 4 to facilitate their eventual 
removal from the language.

Proposed solution

Construction of Tuple Shuffle Expressions will become a warning in Swift 3 
compatibility mode and will be a hard-error in Swift 4.

Detailed design

In addition to the necessary diagnostics, the grammar will be ammended to 
simplify the following productions:

tuple-pattern → (tuple-pattern-element-list )
tuple-pattern-element-list → tuple-pattern-element | tuple-pattern-element , 
tuple-pattern-element-list
- tuple-pattern-element → pattern | identifier:pattern
+ tuple-pattern-element → pattern
Impact on Existing Code

Because very little code is intentionally using Tuple Shuffles, impact on 
existing code will be negligible but not non-zero.

Alternatives considered

Continue to keep the architecture in place to facilitate this feature.
___
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] Pitch: Automatically deriving Equatable/Hashable for more value types

[Brent Royal-Gordon via swift-evolution]

> On May 4, 2017, at 3:01 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Hmm, I can see the appeal of automatically deriving Equatable and Hashable 
> conformance, but I'd like that to be opt-in. That is, types should declare 
> that they are Equatable or Hashable to begin with. It wouldn't have to take 
> extra syntax, as compiler magic could effectively synthesize default 
> implementations for == and/or hashValue when all members are themselves 
> Equatable or Hashable, respectively.

Another benefit is that the problem you're currently having with recursion goes 
away: from outside the type, you merely need to check if conformance is 
declared.

Explicit with no special syntactic marker is definitely the way to go. It would 
work just like Codable is slated to.

> With such a scheme, consideration can be made to accommodating classes too.


I would think only final classes could participate in this, since a 
subclassable class would need to allow subclasses to override equality, and you 
can't override a static `==` operator method.

(My time is not unlimited right now, but I'd be willing to help with either the 
proposal or its implementation. This would be a great thing to get into Swift 
4.)

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

[Robert Widmann via swift-evolution]

None of those are affected.  See the note in the proposal.

~Robert Widmann

> On May 5, 2017, at 1:16 AM, Adrian Zubarev  
> wrote:
> 
> Hi Robert,
> 
> I’m trying to understand the impact of your proposal and the feature you want 
> to remove from the language. Could you describe a little more on how if ever 
> this affects tuple destructuring? 
> 
> var (a, b, c) = (0, "", 0)
> 
> (a, b) = (42, "Hello Swift")
> 
> (a = 42, b = "Hello Swift")
> 
> var (x, y) = (0, 42)
> 
> (x, y) = (y, x) // swap without a temporary value
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 5. Mai 2017 um 04:15:12, Robert Widmann via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> Hi all,
>> 
>> So sorry that this proposal comes so late in the game, but I feel it’s too 
>> important not to bring it to the attention of the community now.  Attached 
>> is a proposal to deprecate a language feature many of you will probably have 
>> never had the chance to use: Tuple Shuffles.  I’ve attached a copy of the 
>> first draft of the proposal below, but the latest copy can be read on Github 
>> .
>> 
>> Thanks!
>> 
>> ~Robert Widmann
>> 
>> Deprecate Tuple Shuffles
>> Proposal: SE- 
>> 
>> Authors: Robert Widmann 
>> Review Manager: TBD
>> Status: Awaiting review
>>  
>> Introduction
>> 
>> This proposal seeks the deprecation of a little-known feature of Swift 
>> called a "Tuple Shuffle".
>> 
>>  
>> Motivation
>> 
>> A tuple-shuffle is an undocumented feature of Swift in which one can 
>> re-order the indices of a tuple by writing a pattern that describes a 
>> permutation in a syntax reminiscent of adding type-annotations to a 
>> parameter list:
>> 
>> let a = (x: 1, y: 2)
>> var b: (y: Int, x: Int)
>> b = a
>> It can be used to simultaneously destructure and reorder a tuple:
>> 
>> let tuple = (first: 0, second: (x: 1, y: 2))
>> let (second: (x: b, y: c), first: a) = tuple
>> It can also be used to map parameter labels out of order in a call 
>> expression:
>> 
>> func foo(_ : (x : Int, y : Int)) {}
>> foo((y: 5, x: 10)) // Valid
>> Note that a tuple shuffle is distinct from a re-assignment through a tuple 
>> pattern. For example, this series of statements will continue to function as 
>> before:
>> 
>> var x = 5
>> var y = 10
>> var z = 15
>> (z, y, x) = (x, z, y)
>> Their inclusion in the language complicates every part of the compiler 
>> stack, uses a syntax that can be confused for type annotations 
>> , contradicts the 
>> goals of earlier SE's (see SE-0060 
>> ),
>>  and makes non-sensical patterns possible in surprising places.
>> 
>> Take switch-statements, for example:
>> 
>> switch ((0, 0), 0){  
>> case (_ : let (y, z), _ : let s): () // We are forbidden from giving these 
>> patterns names other than "_" 
>> default: ()  
>> }
>> This proposal seeks to deprecate them in Swift 3 compatibility mode and 
>> enforce that deprecation as a hard error in Swift 4 to facilitate their 
>> eventual removal from the language.
>> 
>>  
>> Proposed
>>  solution
>> 
>> Construction of Tuple Shuffle Expressions will become a warning in Swift 3 
>> compatibility mode and will be a hard-error in Swift 4.
>> 
>>  
>> Detailed
>>  design
>> 
>> In addition to the necessary diagnostics, the grammar will be ammended to 
>> simplify the following productions:
>> 
>> tuple-pattern → (tuple-pattern-element-list )
>> tuple-pattern-element-list → tuple-pattern-element | tuple-pattern-element , 
>> tuple-pattern-element-list
>> - tuple-pattern-element → pattern | identifier:pattern
>> + tuple-pattern-element → pattern
>>  
>> Impact
>>  on Existing Code
>> 
>> Because very little code is intentionally using Tuple Shuffles, impact on 
>> existing code will be negligible but not non-zero.
>> 
>>  
>> 

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

[Robert Widmann via swift-evolution]

On the contrary, this is precisely what it means to deprecate tuple shuffles.  
You can’t map common parlance onto this term; the proposal and the Twitter 
thread weren’t merely about reordering arguments.

> but it is entirely another ballgame to remove labels from tuple patterns 
> altogether.

It’s really not.  Let me demonstrate:

> To be clear, are you proposing the prohibition of *adding or removing* labels 
> as well? A previous discussion on tuple shuffling on this list saw consensus 
> that assigning a value of type (label1: T, label2: U) to a variable of type 
> (T, U) and vice versa should absolutely be supported, whether or not 
> reordering is permitted.

I am not proposing any changes to switching parameter labels through well-typed 
re-assignments.  This is absolutely still going to be allowed:

var z : (Int, Int) = (0, 0)
var w : (x : Int, y : Int) = (5, 10)
z = w
w = z

This is modeled internally with a tuple shuffle, but not the kind of shuffle 
I’m interested in banning.  It’s a far simpler kind of 

> And how about *restating* existing labels without any adding or removing? To 
> be clear:
> 
> ```
> let (partialValue: v, overflow: o) = 42.addingReportingOverflow(42)
> ```
> 
> ...involves absolutely no changes in labels whatsoever. The return type is 
> (partialValue: Int, overflow: ArithmeticOverflow).

That, however, is a kind of shuffle I intend to deprecate here.  This kind of 
pattern is subject to the “arcane syntax” part of the proposal.

> 
> Either one of these scenarios is commonly used, and it is astonishing to me 
> that they would be eliminated.

Do you have proof of that claim? I have never seen the relevant kinds of tuple 
shuffle used before, and I doubt you have either before today.

~Robert Widmann

> On May 5, 2017, at 12:53 AM, Xiaodi Wu  wrote:
> 
> Ah, I see from your proposed grammar update: you're proposing to prohibit the 
> use of labels entirely in a tuple pattern.
> 
> This is much more than just prohibiting tuple shuffling, and I'm rather 
> disappointed that you described such a dramatic change using a corner case. 
> There are very good reasons why someone finds 'let (y: x, x: y) = (x: 1, y: 
> 2)' confusing and would support its removal, but it is entirely another 
> ballgame to remove labels from tuple patterns altogether.
> 
> 
> On Thu, May 4, 2017 at 23:47 Xiaodi Wu  > wrote:
> Now I'm confused. The ordinary meaning of the word "shuffle" is not changing 
> but rather reordering, and all of your examples are of reordering.
> 
> To be clear, are you proposing the prohibition of *adding or removing* labels 
> as well? A previous discussion on tuple shuffling on this list saw consensus 
> that assigning a value of type (label1: T, label2: U) to a variable of type 
> (T, U) and vice versa should absolutely be supported, whether or not 
> reordering is permitted.
> 
> And how about *restating* existing labels without any adding or removing? To 
> be clear:
> 
> ```
> let (partialValue: v, overflow: o) = 42.addingReportingOverflow(42)
> ```
> 
> ...involves absolutely no changes in labels whatsoever. The return type is 
> (partialValue: Int, overflow: ArithmeticOverflow).
> 
> Either one of these scenarios is commonly used, and it is astonishing to me 
> that they would be eliminated.
> 
> On Thu, May 4, 2017 at 23:28 Robert Widmann  > wrote:
> That doesn't involve a parameter reordering, but because it changes argument 
> labels it's a shuffle.
> 
> ~Robert Widmann
> 
> 2017/05/05 0:16、Xiaodi Wu > 
> のメッセージ:
> 
>> Robert,
>> 
>> As I mentioned on Twitter, getting rid of tuple shuffles would not cure your 
>> example, which does not involve a shuffle. Unless you're proposing to 
>> disallow the use of labels during destructuring entirely, which I would 
>> think to be very much unacceptable. Example:
>> 
>> ```
>> let (partialValue: v, overflow: o) = 42.addingReportingOverflow(42)
>> ```
>> 
>> This involves no shuffling and should absolutely remain allowed.
>> 
>> 
>> On Thu, May 4, 2017 at 21:15 Robert Widmann via swift-evolution 
>> > wrote:
>> Hi all,
>> 
>> So sorry that this proposal comes so late in the game, but I feel it’s too 
>> important not to bring it to the attention of the community now.  Attached 
>> is a proposal to deprecate a language feature many of you will probably have 
>> never had the chance to use: Tuple Shuffles.  I’ve attached a copy of the 
>> first draft of the proposal below, but the latest copy can be read on Github 
>> .
>> 
>> Thanks!
>> 
>> ~Robert Widmann
>> 
>> Deprecate Tuple Shuffles
>> 
>> Proposal: SE- 
>> 

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

[Adrian Zubarev via swift-evolution]

Hi Robert,

I’m trying to understand the impact of your proposal and the feature you want 
to remove from the language. Could you describe a little more on how if ever 
this affects tuple destructuring?

var (a, b, c) = (0, "", 0)

(a, b) = (42, "Hello Swift")

(a = 42, b = "Hello Swift")

var (x, y) = (0, 42)

(x, y) = (y, x) // swap without a temporary value


-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 04:15:12, Robert Widmann via swift-evolution 
(swift-evolution@swift.org) schrieb:

Hi all,

So sorry that this proposal comes so late in the game, but I feel it’s too 
important not to bring it to the attention of the community now.  Attached is a 
proposal to deprecate a language feature many of you will probably have never 
had the chance to use: Tuple Shuffles.  I’ve attached a copy of the first draft 
of the proposal below, but the latest copy can be read on Github.

Thanks!

~Robert Widmann

Deprecate Tuple Shuffles
Proposal: SE-
Authors: Robert Widmann
Review Manager: TBD
Status: Awaiting review
Introduction

This proposal seeks the deprecation of a little-known feature of Swift called a 
"Tuple Shuffle".

Motivation

A tuple-shuffle is an undocumented feature of Swift in which one can re-order 
the indices of a tuple by writing a pattern that describes a permutation in a 
syntax reminiscent of adding type-annotations to a parameter list:

let a = (x: 1, y: 2)
var b: (y: Int, x: Int)
b = a
It can be used to simultaneously destructure and reorder a tuple:

let tuple = (first: 0, second: (x: 1, y: 2))
let (second: (x: b, y: c), first: a) = tuple
It can also be used to map parameter labels out of order in a call expression:

func foo(_ : (x : Int, y : Int)) {}
foo((y: 5, x: 10)) // Valid
Note that a tuple shuffle is distinct from a re-assignment through a tuple 
pattern. For example, this series of statements will continue to function as 
before:

var x = 5
var y = 10
var z = 15
(z, y, x) = (x, z, y)
Their inclusion in the language complicates every part of the compiler stack, 
uses a syntax that can be confused for type annotations, contradicts the goals 
of earlier SE's (see SE-0060), and makes non-sensical patterns possible in 
surprising places.

Take switch-statements, for example:

switch ((0, 0), 0){  
case (_ : let (y, z), _ : let s): () // We are forbidden from giving these 
patterns names other than "_"  
default: ()  
}
This proposal seeks to deprecate them in Swift 3 compatibility mode and enforce 
that deprecation as a hard error in Swift 4 to facilitate their eventual 
removal from the language.

Proposed solution

Construction of Tuple Shuffle Expressions will become a warning in Swift 3 
compatibility mode and will be a hard-error in Swift 4.

Detailed design

In addition to the necessary diagnostics, the grammar will be ammended to 
simplify the following productions:

tuple-pattern → (tuple-pattern-element-list )
tuple-pattern-element-list → tuple-pattern-element | tuple-pattern-element , 
tuple-pattern-element-list
- tuple-pattern-element → pattern | identifier:pattern
+ tuple-pattern-element → pattern
Impact on Existing Code

Because very little code is intentionally using Tuple Shuffles, impact on 
existing code will be negligible but not non-zero.

Alternatives considered

Continue to keep the architecture in place to facilitate this feature.
___
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] Pitch: Automatically deriving Equatable/Hashable for more value types

[Xiaodi Wu via swift-evolution]

I see. You're not suggesting magic.

The problem stands that the design of Equatable explicitly encourages the
distinction between identity and equality (it even says: "equality is
separate from identity"). It follows that we should *not* provide a default
implementation that forwards one to the other; if someone determines that
this is right for their particular class, then they can trivially write it
themselves.

This goes back to the very high bar for inclusion of something in the
standard library. An additional protocol like this needs to hold its own
weight, encourage rather than discourage patterns that we aim to promote,
help avoid rather than promote misuse, be commonly useful, and be difficult
to write on one's own--among other criteria outlined by Ben Cohen. For many
of these criteria, I think your proposed protocol does not pass the bar.

On Fri, May 5, 2017 at 00:06 Charlie Monroe 
wrote:

> On May 5, 2017, at 6:58 AM, Xiaodi Wu  wrote:
>
> As the documentation for Equatable discusses, the goal is to distinguish
> "equality" (==) from "identity" (===). If I understand it correctly, the
> goal is to *discourage* mixing the two concepts.
>
> Moreover, while writing a memberwise comparison is tedious and writing a
> memberwise hash is even error-prone, writing "return lhs === rhs" is both
> straightforward and impossible to mess up, so having special magic for that
> use case is much harder to justify.
>
>
> There doesn't need to be any magic - why would there need to be?
>
> public protocol PointerEquatable: AnyObject, Equatable, Hashable {
>
> public static func ==(lhs: Self, rhs: Self) -> Bool {
> return lhs === rhs
> }
>
> public var hashValue: Int {
> return ObjectIdentifier(self).hashValue
> }
>
> }
>
> I'm not saying it's super hard but while we're at it, we might as well
> include something like this in case identity is enough for equality, in
> such case
>
> class Foo: PointerEquatable { }
>
> is enough for the class to be hashable and equatable. It's all opt-in,
> there's no magic - I don't quite see the downside to it.
>
>
> On Thu, May 4, 2017 at 23:45 Charlie Monroe via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> I'm also leaning towards this being opt-in and the generation could be
>> triggered by having AutoEquatable and AutoHashable protocols.
>>
>> Any chance for this proposal to be extended by adding "PointerEquatable"
>> for classes? In many cases, pointer equality is just enough and having the
>> class equatable by pointer allows e.g. better array inter-op (e.g. removing
>> an object doesn't require getting an index first)...
>>
>>
>>
>> On May 4, 2017, at 10:37 PM, Tony Allevato via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Hi all,
>>
>> A conversation on Twitter last night brought up some interest in this
>> feature and I was encouraged to revive this proposal.
>>
>> Jordan Rose mentioned
>>  on Twitter that
>> it could possibly make it in by the Swift 4 deadline if others
>> contributed—I have a WIP branch (albeit not currently working because I
>> rebased after a couple months of it being idle) that does the work for
>> enums but I got stuck on the mutually recursive cases. If this got
>> approved, I'd love to collaborate with other interested folks to finish up
>> the implementation.
>>
>> Link: https://gist.github.com/allevato/2fd10290bfa84accfbe977d8ac07daad
>>
>>
>> Deriving Equatable and Hashable for value types
>>
>>- Proposal: SE-
>>
>> 
>>- Author(s): Tony Allevato 
>>- Status: Awaiting review
>>
>> 
>>- Review manager: TBD
>>
>>
>> 
>> Introduction
>>
>> Value types are prevalent throughout the Swift language, and we encourage
>> developers to think in those terms when writing their own types.
>> Frequently, developers have to write large amounts of boilerplate code to
>> support equatability and hashability of value types. This proposal offers a
>> way for the compiler to automatically derive conformance to Equatable and
>>  Hashable to reduce this boilerplate, in a subset of scenarios where
>> generating the correct implementation is known to be possible.
>>
>> Swift-evolution thread: Universal Equatability, Hashability, and
>> Comparability
>> 
>>
>> 
>> Motivation
>>
>> Building robust value types in Swift can involve writing significant
>> boilerplate code to support hashability and equatability. Equality is
>> pervasive across many value types, and for each one users must implement the
>>  == 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0176: Enforce Exclusive Access to Memory

[Paul Cantrell via swift-evolution]

Thanks for these reassurances, John. This is the sort of feature that calls for 
an iterative design-implement-design sort of process, so it’s good to know 
you’ve already done the static analysis explorations you describe. Given what 
you wrote, and given the apparent importance of this proposal to the large 
memory vision, I’m now +1.

This feature calls to mind two things I remember Chris Lattner wrote in the 
early days of the list. The first is that he preferred that Swift stick with 
design ideas that have been proved out in other languages. The second is that 
he’s concerned with the “programmer model” that features create — the whole 
ecosystem of habits, best practices, tools, and mental models that form around 
a language’s approach.

This whole constellation of memory seems to me to be fairly novel. (Maybe a 
little Rust-like? But very much its own beast. I don’t know of clear precedent 
for all of this in other languages.) It also seems this will all have a strong 
bearing on the programmer model, but it’s hard to fully anticipate how.

I’m nervous about how the evolution process will handle a design problem of 
this kind. My trust in the core team’s good judgement tempers that nervousness.

> We were initially considering the use of "access underway" flags, but 
> eventually decided that it made more sense to use a separate global tracking 
> system.  Currently this table is thread-local

Fascinating! I’m surprised that a table you have to scan beats flags with known 
offsets. Maybe the small size of that table has less cache impact than larger 
objects? Or is it just a space vs. time tradeoff, and you chose space? Then 
again, maybe it’s better that I don’t know how the sausage is made!

> In your experiments, you've no doubt observed that it takes some effort to 
> actually get an access to be non-instantaneous.

*smirk*

Cheers, P


> On May 3, 2017, at 10:43 AM, John McCall  wrote:
> 
>> On May 3, 2017, at 12:05 AM, Paul Cantrell via swift-evolution 
>> > wrote:
>> I like the spirit of the proposal. It leaves me a bit uneasy because the 
>> practical ramifications are difficult to fully anticipate. Here follow some 
>> questions / concerns for the proposal authors.
>> 
>> (Apologies if these were answered somewhere deep in a discussion thread; 
>> it’s the end of the semester and I’ve not kept up with the list.)
>> 
>> • • •
>> 
>> First, have you done any systematic exploration of how impactful this rule 
>> is? The proposal states in several places that it hopes/expects violations 
>> will be rare, but is that empirical or speculative?
> 
> Initially, it was just well-informed speculation, but we're gathering more 
> and more evidence that it's borne out in practice.  Even large code bases 
> have at most a couple of static violations, and that's before we've 
> implemented some of the refinements around struct properties.
> 
>> I tried playing around with the implications, thought I’d found a 
>> problematic example by writing an in-place Array.shuffle() method — and then 
>> was pleased to realize that the proposal already covered my example with 
>> swapAt(). In half an hour, I couldn’t come up with something the proposal 
>> disallows that it clearly should allow.
>> 
>> Still, the implications of a rule like this are difficult to anticipate. It 
>> would be interesting to know how many errors it flags in the Swift source 
>> compatibility suite, for example. Is that something we could do before going 
>> all-in on a fully robust implementation?
> 
> That is definitely an experiment we're running.  Unfortunately, we can only 
> test for static violations with this, because checking for dynamic violations 
> requires execution tests.
> 
>> Second, what are the performance implications of dynamic exclusivity 
>> enforcement? Introducing overhead to something as basic as variable access 
>> seems dicey. Will it kill “C-like” performance for object properties? For 
>> closure vars?
> 
> It will definitely add overhead to class member access, global variable 
> access, and closure access.  Optimization may be able to reduce those 
> overheads; for example, we can look at every use of a private property and 
> often quickly prove that it is impossible to have an access violation on it.  
> (That can be extended to internal properties in WMO builds; it is impossible 
> for open properties.)
> 
>> Will “accesses underway” flags add to the memory footprint of every object & 
>> every closure?
> 
> We were initially considering the use of "access underway" flags, but 
> eventually decided that it made more sense to use a separate global tracking 
> system.  Currently this table is thread-local, and we expect it to be small 
> enough at any given time that a linear scan will perform acceptably.  (In 
> your experiments, you've no doubt observed that it takes some effort to 
> actually get an access to be 

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

[Charlie Monroe via swift-evolution]

> On May 5, 2017, at 6:58 AM, Xiaodi Wu  wrote:
> 
> As the documentation for Equatable discusses, the goal is to distinguish 
> "equality" (==) from "identity" (===). If I understand it correctly, the goal 
> is to *discourage* mixing the two concepts.
> 
> Moreover, while writing a memberwise comparison is tedious and writing a 
> memberwise hash is even error-prone, writing "return lhs === rhs" is both 
> straightforward and impossible to mess up, so having special magic for that 
> use case is much harder to justify.

There doesn't need to be any magic - why would there need to be?

public protocol PointerEquatable: AnyObject, Equatable, Hashable {

public static func ==(lhs: Self, rhs: Self) -> Bool {
return lhs === rhs
}

public var hashValue: Int {
return ObjectIdentifier(self).hashValue
}

}

I'm not saying it's super hard but while we're at it, we might as well include 
something like this in case identity is enough for equality, in such case

class Foo: PointerEquatable { }

is enough for the class to be hashable and equatable. It's all opt-in, there's 
no magic - I don't quite see the downside to it.


> On Thu, May 4, 2017 at 23:45 Charlie Monroe via swift-evolution 
> > wrote:
> I'm also leaning towards this being opt-in and the generation could be 
> triggered by having AutoEquatable and AutoHashable protocols.
> 
> Any chance for this proposal to be extended by adding "PointerEquatable" for 
> classes? In many cases, pointer equality is just enough and having the class 
> equatable by pointer allows e.g. better array inter-op (e.g. removing an 
> object doesn't require getting an index first)...
> 
> 
> 
>> On May 4, 2017, at 10:37 PM, Tony Allevato via swift-evolution 
>> > wrote:
>> 
>> Hi all,
>> 
>> A conversation on Twitter last night brought up some interest in this 
>> feature and I was encouraged to revive this proposal.
>> 
>> Jordan Rose mentioned 
>>  on Twitter that it 
>> could possibly make it in by the Swift 4 deadline if others contributed—I 
>> have a WIP branch (albeit not currently working because I rebased after a 
>> couple months of it being idle) that does the work for enums but I got stuck 
>> on the mutually recursive cases. If this got approved, I'd love to 
>> collaborate with other interested folks to finish up the implementation.
>> 
>> Link: https://gist.github.com/allevato/2fd10290bfa84accfbe977d8ac07daad 
>> 
>> 
>> 
>> Deriving Equatable and Hashable for value types
>> 
>> Proposal: SE- 
>> 
>> Author(s): Tony Allevato 
>> Status: Awaiting review 
>> 
>> Review manager: TBD
>>  
>> Introduction
>> 
>> Value types are prevalent throughout the Swift language, and we encourage 
>> developers to think in those terms when writing their own types. Frequently, 
>> developers have to write large amounts of boilerplate code to support 
>> equatability and hashability of value types. This proposal offers a way for 
>> the compiler to automatically derive conformance to Equatable and Hashable 
>> to reduce this boilerplate, in a subset of scenarios where generating the 
>> correct implementation is known to be possible.
>> 
>> Swift-evolution thread: Universal Equatability, Hashability, and 
>> Comparability 
>>  
>> Motivation
>> 
>> Building robust value types in Swift can involve writing significant 
>> boilerplate code to support hashability and equatability. Equality is 
>> pervasive across many value types, and for each one users must implement the 
>> == operator such that it performs a fairly rote memberwise equality test. As 
>> an example, an equality test for a struct looks fairly uninteresting:
>> 
>> struct Foo: Equatable {
>>   static func == (lhs: Foo, rhs: Foo) -> Bool {
>> return lhs.property1 == rhs.property1 &&
>>lhs.property2 == rhs.property2 &&
>>lhs.property3 == rhs.property3 &&
>>...
>>   }
>> }
>> What's worse is that this operator must be updated if any properties are 
>> added, removed, or changed, and since it must be manually written, it's 
>> possible to get it wrong, either by omission or typographical error.
>> 
>> Likewise, hashability is necessary when one wishes to store a value type in 
>> a Set or use one as a multi-valued Dictionary key. Writing 

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

[Xiaodi Wu via swift-evolution]

As the documentation for Equatable discusses, the goal is to distinguish
"equality" (==) from "identity" (===). If I understand it correctly, the
goal is to *discourage* mixing the two concepts.

Moreover, while writing a memberwise comparison is tedious and writing a
memberwise hash is even error-prone, writing "return lhs === rhs" is both
straightforward and impossible to mess up, so having special magic for that
use case is much harder to justify.
On Thu, May 4, 2017 at 23:45 Charlie Monroe via swift-evolution <
swift-evolution@swift.org> wrote:

> I'm also leaning towards this being opt-in and the generation could be
> triggered by having AutoEquatable and AutoHashable protocols.
>
> Any chance for this proposal to be extended by adding "PointerEquatable"
> for classes? In many cases, pointer equality is just enough and having the
> class equatable by pointer allows e.g. better array inter-op (e.g. removing
> an object doesn't require getting an index first)...
>
>
>
> On May 4, 2017, at 10:37 PM, Tony Allevato via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi all,
>
> A conversation on Twitter last night brought up some interest in this
> feature and I was encouraged to revive this proposal.
>
> Jordan Rose mentioned
>  on Twitter that
> it could possibly make it in by the Swift 4 deadline if others
> contributed—I have a WIP branch (albeit not currently working because I
> rebased after a couple months of it being idle) that does the work for
> enums but I got stuck on the mutually recursive cases. If this got
> approved, I'd love to collaborate with other interested folks to finish up
> the implementation.
>
> Link: https://gist.github.com/allevato/2fd10290bfa84accfbe977d8ac07daad
>
>
> Deriving Equatable and Hashable for value types
>
>- Proposal: SE-
>
> 
>- Author(s): Tony Allevato 
>- Status: Awaiting review
>
> 
>- Review manager: TBD
>
>
> 
> Introduction
>
> Value types are prevalent throughout the Swift language, and we encourage
> developers to think in those terms when writing their own types.
> Frequently, developers have to write large amounts of boilerplate code to
> support equatability and hashability of value types. This proposal offers a
> way for the compiler to automatically derive conformance to Equatable and
> Hashable to reduce this boilerplate, in a subset of scenarios where
> generating the correct implementation is known to be possible.
>
> Swift-evolution thread: Universal Equatability, Hashability, and
> Comparability
> 
>
> 
> Motivation
>
> Building robust value types in Swift can involve writing significant
> boilerplate code to support hashability and equatability. Equality is
> pervasive across many value types, and for each one users must implement the
>  == operator such that it performs a fairly rote memberwise equality
> test. As an example, an equality test for a struct looks fairly
> uninteresting:
>
> struct Foo: Equatable {
>   static func == (lhs: Foo, rhs: Foo) -> Bool {
> return lhs.property1 == rhs.property1 &&
>lhs.property2 == rhs.property2 &&
>lhs.property3 == rhs.property3 &&
>...
>   }
> }
>
> What's worse is that this operator must be updated if any properties are
> added, removed, or changed, and since it must be manually written, it's
> possible to get it wrong, either by omission or typographical error.
>
> Likewise, hashability is necessary when one wishes to store a value type
> in a Set or use one as a multi-valued Dictionary key. Writing
> high-quality, well-distributed hash functions is not trivial so developers
> may not put a great deal of thought into them – especially as the number of
> properties increases – not realizing that their performance could
> potentially suffer as a result. And as with equality, writing it manually
> means there is the potential to get it wrong.
>
> In particular, the code that must be written to implement equality for
> enums is quite verbose:
>
> enum Token: Equatable {
>   case string(String)
>   case number(Int)
>   case lparen
>   case rparen
>
>   static func == (lhs: Token, rhs: Token) -> Bool {
> switch (lhs, rhs) {
> case (.string(let lhsString), .string(let rhsString)):
>   return lhsString == rhsString
> case (.number(let lhsNumber), .number(let lhsNumber)):
>   return lhsNumber == rhsNumber
> case (.lparen, .lparen), (.rparen, .rparen):
>   return true
> default:
>   return false
> }
>   }
> }
>
> Crafting a high-quality hash 

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

[Xiaodi Wu via swift-evolution]

Ah, I see from your proposed grammar update: you're proposing to prohibit
the use of labels entirely in a tuple pattern.

This is much more than just prohibiting tuple shuffling, and I'm rather
disappointed that you described such a dramatic change using a corner case.
There are very good reasons why someone finds 'let (y: x, x: y) = (x: 1, y:
2)' confusing and would support its removal, but it is entirely another
ballgame to remove labels from tuple patterns altogether.


On Thu, May 4, 2017 at 23:47 Xiaodi Wu  wrote:

> Now I'm confused. The ordinary meaning of the word "shuffle" is not
> changing but rather reordering, and all of your examples are of reordering.
>
> To be clear, are you proposing the prohibition of *adding or removing*
> labels as well? A previous discussion on tuple shuffling on this list saw
> consensus that assigning a value of type (label1: T, label2: U) to a
> variable of type (T, U) and vice versa should absolutely be supported,
> whether or not reordering is permitted.
>
> And how about *restating* existing labels without any adding or removing?
> To be clear:
>
> ```
> let (partialValue: v, overflow: o) = 42.addingReportingOverflow(42)
> ```
>
> ...involves absolutely no changes in labels whatsoever. The return type is
> (partialValue: Int, overflow: ArithmeticOverflow).
>
> Either one of these scenarios is commonly used, and it is astonishing to
> me that they would be eliminated.
>
> On Thu, May 4, 2017 at 23:28 Robert Widmann 
> wrote:
>
>> That doesn't involve a parameter *reordering*, but because it changes
>> argument labels it's a shuffle.
>>
>> ~Robert Widmann
>>
>> 2017/05/05 0:16、Xiaodi Wu  のメッセージ:
>>
>> Robert,
>>
>> As I mentioned on Twitter, getting rid of tuple shuffles would not cure
>> your example, which does not involve a shuffle. Unless you're proposing to
>> disallow the use of labels during destructuring entirely, which I would
>> think to be very much unacceptable. Example:
>>
>> ```
>> let (partialValue: v, overflow: o) = 42.addingReportingOverflow(42)
>> ```
>>
>> This involves no shuffling and should absolutely remain allowed.
>>
>>
>> On Thu, May 4, 2017 at 21:15 Robert Widmann via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Hi all,
>>>
>>> So sorry that this proposal comes so late in the game, but I feel it’s
>>> too important not to bring it to the attention of the community now.
>>> Attached is a proposal to deprecate a language feature many of you will
>>> probably have never had the chance to use: Tuple Shuffles.  I’ve attached a
>>> copy of the first draft of the proposal below, but the latest copy can be
>>> read on Github 
>>> .
>>>
>>> Thanks!
>>>
>>> ~Robert Widmann
>>>
>>> Deprecate Tuple Shuffles
>>>
>>>- Proposal: SE-
>>>
>>> 
>>>- Authors: Robert Widmann 
>>>- Review Manager: TBD
>>>- Status: Awaiting review
>>>
>>>
>>> 
>>> Introduction
>>>
>>> This proposal seeks the deprecation of a little-known feature of Swift
>>> called a "Tuple Shuffle".
>>>
>>> 
>>> Motivation
>>>
>>> A tuple-shuffle is an undocumented feature of Swift in which one can
>>> re-order the indices of a tuple by writing a pattern that describes a
>>> permutation in a syntax reminiscent of adding type-annotations to a
>>> parameter list:
>>>
>>> let a = (x: 1, y: 2)var b: (y: Int, x: Int)
>>> b = a
>>>
>>> It can be used to simultaneously destructure and reorder a tuple:
>>>
>>> let tuple = (first: 0, second: (x: 1, y: 2))let (second: (x: b, y: c), 
>>> first: a) = tuple
>>>
>>> It can also be used to map parameter labels out of order in a call
>>> expression:
>>>
>>> func foo(_ : (x : Int, y : Int)) {}foo((y: 5, x: 10)) // Valid
>>>
>>> Note that a tuple shuffle is distinct from a re-assignment through a
>>> tuple pattern. For example, this series of statements will continue to
>>> function as before:
>>>
>>> var x = 5var y = 10var z = 15
>>> (z, y, x) = (x, z, y)
>>>
>>> Their inclusion in the language complicates every part of the compiler
>>> stack, uses a syntax that can be confused for type annotations
>>> , contradicts
>>> the goals of earlier SE's (see SE-0060
>>> ),
>>> and makes non-sensical patterns possible in surprising places.
>>>
>>> Take switch-statements, for example:
>>>
>>> switch 

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

[Xiaodi Wu via swift-evolution]

Now I'm confused. The ordinary meaning of the word "shuffle" is not
changing but rather reordering, and all of your examples are of reordering.

To be clear, are you proposing the prohibition of *adding or removing*
labels as well? A previous discussion on tuple shuffling on this list saw
consensus that assigning a value of type (label1: T, label2: U) to a
variable of type (T, U) and vice versa should absolutely be supported,
whether or not reordering is permitted.

And how about *restating* existing labels without any adding or removing?
To be clear:

```
let (partialValue: v, overflow: o) = 42.addingReportingOverflow(42)
```

...involves absolutely no changes in labels whatsoever. The return type is
(partialValue: Int, overflow: ArithmeticOverflow).

Either one of these scenarios is commonly used, and it is astonishing to me
that they would be eliminated.

On Thu, May 4, 2017 at 23:28 Robert Widmann 
wrote:

> That doesn't involve a parameter *reordering*, but because it changes
> argument labels it's a shuffle.
>
> ~Robert Widmann
>
> 2017/05/05 0:16、Xiaodi Wu  のメッセージ:
>
> Robert,
>
> As I mentioned on Twitter, getting rid of tuple shuffles would not cure
> your example, which does not involve a shuffle. Unless you're proposing to
> disallow the use of labels during destructuring entirely, which I would
> think to be very much unacceptable. Example:
>
> ```
> let (partialValue: v, overflow: o) = 42.addingReportingOverflow(42)
> ```
>
> This involves no shuffling and should absolutely remain allowed.
>
>
> On Thu, May 4, 2017 at 21:15 Robert Widmann via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Hi all,
>>
>> So sorry that this proposal comes so late in the game, but I feel it’s
>> too important not to bring it to the attention of the community now.
>> Attached is a proposal to deprecate a language feature many of you will
>> probably have never had the chance to use: Tuple Shuffles.  I’ve attached a
>> copy of the first draft of the proposal below, but the latest copy can be
>> read on Github .
>>
>> Thanks!
>>
>> ~Robert Widmann
>>
>> Deprecate Tuple Shuffles
>>
>>- Proposal: SE-
>>
>> 
>>- Authors: Robert Widmann 
>>- Review Manager: TBD
>>- Status: Awaiting review
>>
>>
>> 
>> Introduction
>>
>> This proposal seeks the deprecation of a little-known feature of Swift
>> called a "Tuple Shuffle".
>>
>> 
>> Motivation
>>
>> A tuple-shuffle is an undocumented feature of Swift in which one can
>> re-order the indices of a tuple by writing a pattern that describes a
>> permutation in a syntax reminiscent of adding type-annotations to a
>> parameter list:
>>
>> let a = (x: 1, y: 2)var b: (y: Int, x: Int)
>> b = a
>>
>> It can be used to simultaneously destructure and reorder a tuple:
>>
>> let tuple = (first: 0, second: (x: 1, y: 2))let (second: (x: b, y: c), 
>> first: a) = tuple
>>
>> It can also be used to map parameter labels out of order in a call
>> expression:
>>
>> func foo(_ : (x : Int, y : Int)) {}foo((y: 5, x: 10)) // Valid
>>
>> Note that a tuple shuffle is distinct from a re-assignment through a
>> tuple pattern. For example, this series of statements will continue to
>> function as before:
>>
>> var x = 5var y = 10var z = 15
>> (z, y, x) = (x, z, y)
>>
>> Their inclusion in the language complicates every part of the compiler
>> stack, uses a syntax that can be confused for type annotations
>> , contradicts the
>> goals of earlier SE's (see SE-0060
>> ),
>> and makes non-sensical patterns possible in surprising places.
>>
>> Take switch-statements, for example:
>>
>> switch ((0, 0), 0){ case (_ : let (y, z), _ : let s): () // We are forbidden 
>> from giving these patterns names other than "_" default: ()
>> }
>>
>> This proposal seeks to deprecate them in Swift 3 compatibility mode and
>> enforce that deprecation as a hard error in Swift 4 to facilitate their
>> eventual removal from the language.
>>
>> Proposed
>> solution
>>
>> Construction of Tuple Shuffle Expressions will become a warning in Swift
>> 3 compatibility mode and will be a hard-error in Swift 4.
>>
>> 

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

[Robert Widmann via swift-evolution]

That doesn't involve a parameter reordering, but because it changes argument 
labels it's a shuffle.

~Robert Widmann

2017/05/05 0:16、Xiaodi Wu  のメッセージ:

> Robert,
> 
> As I mentioned on Twitter, getting rid of tuple shuffles would not cure your 
> example, which does not involve a shuffle. Unless you're proposing to 
> disallow the use of labels during destructuring entirely, which I would think 
> to be very much unacceptable. Example:
> 
> ```
> let (partialValue: v, overflow: o) = 42.addingReportingOverflow(42)
> ```
> 
> This involves no shuffling and should absolutely remain allowed.
> 
> 
>> On Thu, May 4, 2017 at 21:15 Robert Widmann via swift-evolution 
>>  wrote:
>> Hi all,
>> 
>> So sorry that this proposal comes so late in the game, but I feel it’s too 
>> important not to bring it to the attention of the community now.  Attached 
>> is a proposal to deprecate a language feature many of you will probably have 
>> never had the chance to use: Tuple Shuffles.  I’ve attached a copy of the 
>> first draft of the proposal below, but the latest copy can be read on Github.
>> 
>> Thanks!
>> 
>> ~Robert Widmann
>> 
>> Deprecate Tuple Shuffles
>> Proposal: SE-
>> Authors: Robert Widmann
>> Review Manager: TBD
>> Status: Awaiting review
>> Introduction
>> 
>> This proposal seeks the deprecation of a little-known feature of Swift 
>> called a "Tuple Shuffle".
>> 
>> Motivation
>> 
>> A tuple-shuffle is an undocumented feature of Swift in which one can 
>> re-order the indices of a tuple by writing a pattern that describes a 
>> permutation in a syntax reminiscent of adding type-annotations to a 
>> parameter list:
>> 
>> let a = (x: 1, y: 2)
>> var b: (y: Int, x: Int)
>> b = a
>> It can be used to simultaneously destructure and reorder a tuple:
>> 
>> let tuple = (first: 0, second: (x: 1, y: 2))
>> let (second: (x: b, y: c), first: a) = tuple
>> It can also be used to map parameter labels out of order in a call 
>> expression:
>> 
>> func foo(_ : (x : Int, y : Int)) {}
>> foo((y: 5, x: 10)) // Valid
>> Note that a tuple shuffle is distinct from a re-assignment through a tuple 
>> pattern. For example, this series of statements will continue to function as 
>> before:
>> 
>> var x = 5
>> var y = 10
>> var z = 15
>> (z, y, x) = (x, z, y)
>> Their inclusion in the language complicates every part of the compiler 
>> stack, uses a syntax that can be confused for type annotations, contradicts 
>> the goals of earlier SE's (see SE-0060), and makes non-sensical patterns 
>> possible in surprising places.
>> 
>> Take switch-statements, for example:
>> 
>> switch ((0, 0), 0){ 
>> case (_ : let (y, z), _ : let s): () // We are forbidden from giving these 
>> patterns names other than "_" 
>> default: () 
>> }
>> This proposal seeks to deprecate them in Swift 3 compatibility mode and 
>> enforce that deprecation as a hard error in Swift 4 to facilitate their 
>> eventual removal from the language.
>> 
>> Proposed solution
>> 
>> Construction of Tuple Shuffle Expressions will become a warning in Swift 3 
>> compatibility mode and will be a hard-error in Swift 4.
>> 
>> Detailed design
>> 
>> In addition to the necessary diagnostics, the grammar will be ammended to 
>> simplify the following productions:
>> 
>> tuple-pattern → (tuple-pattern-element-list )
>> tuple-pattern-element-list → tuple-pattern-element | tuple-pattern-element , 
>> tuple-pattern-element-list
>> - tuple-pattern-element → pattern | identifier:pattern
>> + tuple-pattern-element → pattern
>> Impact on Existing Code
>> 
>> Because very little code is intentionally using Tuple Shuffles, impact on 
>> existing code will be negligible but not non-zero.
>> 
>> Alternatives considered
>> 
>> Continue to keep the architecture in place to facilitate this feature.
>> ___
>> 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] [Proposal][Discussion] Deprecate Tuple Shuffles

[Xiaodi Wu via swift-evolution]

Robert,

As I mentioned on Twitter, getting rid of tuple shuffles would not cure
your example, which does not involve a shuffle. Unless you're proposing to
disallow the use of labels during destructuring entirely, which I would
think to be very much unacceptable. Example:

```
let (partialValue: v, overflow: o) = 42.addingReportingOverflow(42)
```

This involves no shuffling and should absolutely remain allowed.


On Thu, May 4, 2017 at 21:15 Robert Widmann via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi all,
>
> So sorry that this proposal comes so late in the game, but I feel it’s too
> important not to bring it to the attention of the community now.  Attached
> is a proposal to deprecate a language feature many of you will probably
> have never had the chance to use: Tuple Shuffles.  I’ve attached a copy of
> the first draft of the proposal below, but the latest copy can be read on
> Github .
>
> Thanks!
>
> ~Robert Widmann
>
> Deprecate Tuple Shuffles
>
>- Proposal: SE-
>
> 
>- Authors: Robert Widmann 
>- Review Manager: TBD
>- Status: Awaiting review
>
>
> 
> Introduction
>
> This proposal seeks the deprecation of a little-known feature of Swift
> called a "Tuple Shuffle".
>
> 
> Motivation
>
> A tuple-shuffle is an undocumented feature of Swift in which one can
> re-order the indices of a tuple by writing a pattern that describes a
> permutation in a syntax reminiscent of adding type-annotations to a
> parameter list:
>
> let a = (x: 1, y: 2)var b: (y: Int, x: Int)
> b = a
>
> It can be used to simultaneously destructure and reorder a tuple:
>
> let tuple = (first: 0, second: (x: 1, y: 2))let (second: (x: b, y: c), first: 
> a) = tuple
>
> It can also be used to map parameter labels out of order in a call
> expression:
>
> func foo(_ : (x : Int, y : Int)) {}foo((y: 5, x: 10)) // Valid
>
> Note that a tuple shuffle is distinct from a re-assignment through a tuple
> pattern. For example, this series of statements will continue to function
> as before:
>
> var x = 5var y = 10var z = 15
> (z, y, x) = (x, z, y)
>
> Their inclusion in the language complicates every part of the compiler
> stack, uses a syntax that can be confused for type annotations
> , contradicts the
> goals of earlier SE's (see SE-0060
> ),
> and makes non-sensical patterns possible in surprising places.
>
> Take switch-statements, for example:
>
> switch ((0, 0), 0){ case (_ : let (y, z), _ : let s): () // We are forbidden 
> from giving these patterns names other than "_" default: ()
> }
>
> This proposal seeks to deprecate them in Swift 3 compatibility mode and
> enforce that deprecation as a hard error in Swift 4 to facilitate their
> eventual removal from the language.
>
> Proposed
> solution
>
> Construction of Tuple Shuffle Expressions will become a warning in Swift 3
> compatibility mode and will be a hard-error in Swift 4.
>
> Detailed
> design
>
> In addition to the necessary diagnostics, the grammar will be ammended to
> simplify the following productions:
>
> tuple-pattern → (tuple-pattern-element-list )
> tuple-pattern-element-list → tuple-pattern-element | tuple-pattern-element , 
> tuple-pattern-element-list- tuple-pattern-element → pattern | 
> identifier:pattern+ tuple-pattern-element → pattern
>
>
> Impact
> on Existing Code
>
> Because very little code is intentionally using Tuple Shuffles, impact on
> existing code will be negligible but not non-zero.
>
> Alternatives
> considered
> Continue to keep the architecture in place to facilitate this feature.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

[Jose Cheyo Jimenez via swift-evolution]

I can't think of a single time when I would need a tuple shuffle but I don't 
really work with tuples much. It would be great to hear other people's usage of 
this feature. 

I did not know that types could be overloaded with values. That was very 
surprising to me. Honestly I think that is the issue here. Not sure what can be 
done about it. 

let Int = 5 // works 
let Void = "what?" // works. 


> On May 4, 2017, at 7:14 PM, Robert Widmann via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> So sorry that this proposal comes so late in the game, but I feel it’s too 
> important not to bring it to the attention of the community now.  Attached is 
> a proposal to deprecate a language feature many of you will probably have 
> never had the chance to use: Tuple Shuffles.  I’ve attached a copy of the 
> first draft of the proposal below, but the latest copy can be read on Github.
> 
> Thanks!
> 
> ~Robert Widmann
> 
> Deprecate Tuple Shuffles
> Proposal: SE-
> Authors: Robert Widmann
> Review Manager: TBD
> Status: Awaiting review
> Introduction
> 
> This proposal seeks the deprecation of a little-known feature of Swift called 
> a "Tuple Shuffle".
> 
> Motivation
> 
> A tuple-shuffle is an undocumented feature of Swift in which one can re-order 
> the indices of a tuple by writing a pattern that describes a permutation in a 
> syntax reminiscent of adding type-annotations to a parameter list:
> 
> let a = (x: 1, y: 2)
> var b: (y: Int, x: Int)
> b = a
> It can be used to simultaneously destructure and reorder a tuple:
> 
> let tuple = (first: 0, second: (x: 1, y: 2))
> let (second: (x: b, y: c), first: a) = tuple
> It can also be used to map parameter labels out of order in a call expression:
> 
> func foo(_ : (x : Int, y : Int)) {}
> foo((y: 5, x: 10)) // Valid
> Note that a tuple shuffle is distinct from a re-assignment through a tuple 
> pattern. For example, this series of statements will continue to function as 
> before:
> 
> var x = 5
> var y = 10
> var z = 15
> (z, y, x) = (x, z, y)
> Their inclusion in the language complicates every part of the compiler stack, 
> uses a syntax that can be confused for type annotations, contradicts the 
> goals of earlier SE's (see SE-0060), and makes non-sensical patterns possible 
> in surprising places.
> 
> Take switch-statements, for example:
> 
> switch ((0, 0), 0){ 
> case (_ : let (y, z), _ : let s): () // We are forbidden from giving these 
> patterns names other than "_" 
> default: () 
> }
> This proposal seeks to deprecate them in Swift 3 compatibility mode and 
> enforce that deprecation as a hard error in Swift 4 to facilitate their 
> eventual removal from the language.
> 
> Proposed solution
> 
> Construction of Tuple Shuffle Expressions will become a warning in Swift 3 
> compatibility mode and will be a hard-error in Swift 4.
> 
> Detailed design
> 
> In addition to the necessary diagnostics, the grammar will be ammended to 
> simplify the following productions:
> 
> tuple-pattern → (tuple-pattern-element-list )
> tuple-pattern-element-list → tuple-pattern-element | tuple-pattern-element , 
> tuple-pattern-element-list
> - tuple-pattern-element → pattern | identifier:pattern
> + tuple-pattern-element → pattern
> Impact on Existing Code
> 
> Because very little code is intentionally using Tuple Shuffles, impact on 
> existing code will be negligible but not non-zero.
> 
> Alternatives considered
> 
> Continue to keep the architecture in place to facilitate this feature.
> ___
> 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] [Proposal][Discussion] Deprecate Tuple Shuffles

[Robert Widmann via swift-evolution]

- Parse: Has to account for the inclusion of tuple shuffles whenever it parses 
patterns (see the switch-statement example in the proposal)
- Sema: Has to perform argument matching by computing these tuple shuffle 
mappings thereby complicating the solver and the parts of solution application. 
 Really, the only place this has a valid use is in the error handling path 
where we can use the tuple shuffle to emit a fixit that properly reorders 
arguments - something we should be doing even today 
.  Tuple shuffles are also allowed to 
reorder around variadic arguments which makes matching that much more difficult.
- SIL: Has to account for tuple shuffles in multiple places.  One notable one 
is that SILGen has to support two different paths when lowering tuple shuffles 
- one for variadic shuffles and the other for “normal” shuffles.  Each path 
supports a different subset of the features necessary to implement the full 
feature that is tuple shuffles, neither can really be simplified down to a 
common core in their current iteration.

If you want some numbers, I spent the evening removing them from the codebase 
and came up with a win of about 1500 LoC.  Each line of code supporting a 
feature that people aren’t actually using.

~Robert Widmann


> On May 4, 2017, at 10:35 PM, Tony Arnold via swift-evolution 
>  wrote:
> 
> 
>> On 5 May 2017, at 12:27, Félix Cloutier via swift-evolution 
>>  wrote:
>> 
>> Why?
> 
> Not trying to be smart, but the reasoning is in Robert’s proposal:
> 
>>> Their inclusion in the language complicates every part of the compiler 
>>> stack, uses a syntax that can be confused for type annotations 
>>> (https://twitter.com/CodaFi_/status/860246169854894081), contradicts the 
>>> goals of earlier SE's (see SE-0060), and makes non-sensical patterns 
>>> possible in surprising places.
> 
> 
> Robert, maybe you could include some detail about how this feature is 
> complicating the compiler stack, and what will be improved by it’s removal?
> 
> 
> 
> That being said, I’m all for you guys making your lives easier at the cost of 
> something we shouldn’t be using in the first place…
> 
> 
> Tony
> 
> 
> --
> Tony Arnold
> +61 411 268 532
> http://thecocoabots.com/
> 
> ABN: 14831833541
> 
> ___
> 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] [Proposal][Discussion] Deprecate Tuple Shuffles

[Tony Arnold via swift-evolution]

> On 5 May 2017, at 12:27, Félix Cloutier via swift-evolution 
>  wrote:
> 
> Why?

Not trying to be smart, but the reasoning is in Robert’s proposal:

>> Their inclusion in the language complicates every part of the compiler 
>> stack, uses a syntax that can be confused for type annotations 
>> (https://twitter.com/CodaFi_/status/860246169854894081), contradicts the 
>> goals of earlier SE's (see SE-0060), and makes non-sensical patterns 
>> possible in surprising places.


Robert, maybe you could include some detail about how this feature is 
complicating the compiler stack, and what will be improved by it’s removal?



That being said, I’m all for you guys making your lives easier at the cost of 
something we shouldn’t be using in the first place…


Tony


--
Tony Arnold
+61 411 268 532
http://thecocoabots.com/

ABN: 14831833541

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

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

[Félix Cloutier via swift-evolution]

Why?

> Le 4 mai 2017 à 19:14, Robert Widmann via swift-evolution 
>  a écrit :
> 
> Hi all,
> 
> So sorry that this proposal comes so late in the game, but I feel it’s too 
> important not to bring it to the attention of the community now.  Attached is 
> a proposal to deprecate a language feature many of you will probably have 
> never had the chance to use: Tuple Shuffles.  I’ve attached a copy of the 
> first draft of the proposal below, but the latest copy can be read on Github 
> .
> 
> Thanks!
> 
> ~Robert Widmann
> 
> Deprecate Tuple Shuffles
> 
> Proposal: SE- 
> 
> Authors: Robert Widmann 
> Review Manager: TBD
> Status: Awaiting review
>  
> Introduction
> 
> This proposal seeks the deprecation of a little-known feature of Swift called 
> a "Tuple Shuffle".
> 
>  
> Motivation
> 
> A tuple-shuffle is an undocumented feature of Swift in which one can re-order 
> the indices of a tuple by writing a pattern that describes a permutation in a 
> syntax reminiscent of adding type-annotations to a parameter list:
> 
> let a = (x: 1, y: 2)
> var b: (y: Int, x: Int)
> b = a
> It can be used to simultaneously destructure and reorder a tuple:
> 
> let tuple = (first: 0, second: (x: 1, y: 2))
> let (second: (x: b, y: c), first: a) = tuple
> It can also be used to map parameter labels out of order in a call expression:
> 
> func foo(_ : (x : Int, y : Int)) {}
> foo((y: 5, x: 10)) // Valid
> Note that a tuple shuffle is distinct from a re-assignment through a tuple 
> pattern. For example, this series of statements will continue to function as 
> before:
> 
> var x = 5
> var y = 10
> var z = 15
> (z, y, x) = (x, z, y)
> Their inclusion in the language complicates every part of the compiler stack, 
> uses a syntax that can be confused for type annotations 
> , contradicts the 
> goals of earlier SE's (see SE-0060 
> ),
>  and makes non-sensical patterns possible in surprising places.
> 
> Take switch-statements, for example:
> 
> switch ((0, 0), 0){ 
> case (_ : let (y, z), _ : let s): () // We are forbidden from giving these 
> patterns names other than "_" 
> default: () 
> }
> This proposal seeks to deprecate them in Swift 3 compatibility mode and 
> enforce that deprecation as a hard error in Swift 4 to facilitate their 
> eventual removal from the language.
> 
>  
> Proposed
>  solution
> 
> Construction of Tuple Shuffle Expressions will become a warning in Swift 3 
> compatibility mode and will be a hard-error in Swift 4.
> 
>  
> Detailed
>  design
> 
> In addition to the necessary diagnostics, the grammar will be ammended to 
> simplify the following productions:
> 
> tuple-pattern → (tuple-pattern-element-list )
> tuple-pattern-element-list → tuple-pattern-element | tuple-pattern-element , 
> tuple-pattern-element-list
> - tuple-pattern-element → pattern | identifier:pattern
> + tuple-pattern-element → pattern
>  
> Impact
>  on Existing Code
> 
> Because very little code is intentionally using Tuple Shuffles, impact on 
> existing code will be negligible but not non-zero.
> 
>  
> Alternatives
>  considered
> 
> Continue to keep the architecture in place to facilitate this feature.
> ___
> 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] [Proposal][Discussion] Deprecate Tuple Shuffles

[Robert Widmann via swift-evolution]

Hi all,

So sorry that this proposal comes so late in the game, but I feel it’s too 
important not to bring it to the attention of the community now.  Attached is a 
proposal to deprecate a language feature many of you will probably have never 
had the chance to use: Tuple Shuffles.  I’ve attached a copy of the first draft 
of the proposal below, but the latest copy can be read on Github 
.

Thanks!

~Robert Widmann

Deprecate Tuple Shuffles

Proposal: SE- 

Authors: Robert Widmann 
Review Manager: TBD
Status: Awaiting review
 
Introduction

This proposal seeks the deprecation of a little-known feature of Swift called a 
"Tuple Shuffle".

 
Motivation

A tuple-shuffle is an undocumented feature of Swift in which one can re-order 
the indices of a tuple by writing a pattern that describes a permutation in a 
syntax reminiscent of adding type-annotations to a parameter list:

let a = (x: 1, y: 2)
var b: (y: Int, x: Int)
b = a
It can be used to simultaneously destructure and reorder a tuple:

let tuple = (first: 0, second: (x: 1, y: 2))
let (second: (x: b, y: c), first: a) = tuple
It can also be used to map parameter labels out of order in a call expression:

func foo(_ : (x : Int, y : Int)) {}
foo((y: 5, x: 10)) // Valid
Note that a tuple shuffle is distinct from a re-assignment through a tuple 
pattern. For example, this series of statements will continue to function as 
before:

var x = 5
var y = 10
var z = 15
(z, y, x) = (x, z, y)
Their inclusion in the language complicates every part of the compiler stack, 
uses a syntax that can be confused for type annotations 
, contradicts the goals 
of earlier SE's (see SE-0060 
),
 and makes non-sensical patterns possible in surprising places.

Take switch-statements, for example:

switch ((0, 0), 0){ 
case (_ : let (y, z), _ : let s): () // We are forbidden from giving these 
patterns names other than "_" 
default: () 
}
This proposal seeks to deprecate them in Swift 3 compatibility mode and enforce 
that deprecation as a hard error in Swift 4 to facilitate their eventual 
removal from the language.

 
Proposed
 solution

Construction of Tuple Shuffle Expressions will become a warning in Swift 3 
compatibility mode and will be a hard-error in Swift 4.

 
Detailed
 design

In addition to the necessary diagnostics, the grammar will be ammended to 
simplify the following productions:

tuple-pattern → (tuple-pattern-element-list )
tuple-pattern-element-list → tuple-pattern-element | tuple-pattern-element , 
tuple-pattern-element-list
- tuple-pattern-element → pattern | identifier:pattern
+ tuple-pattern-element → pattern
 
Impact
 on Existing Code

Because very little code is intentionally using Tuple Shuffles, impact on 
existing code will be negligible but not non-zero.

 
Alternatives
 considered

Continue to keep the architecture in place to facilitate this feature.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

[Matthew Johnson via swift-evolution]

> On May 4, 2017, at 5:23 PM, Tony Allevato via swift-evolution 
>  wrote:
> 
> When I initially wrote an earlier version of this proposal last year, I was 
> imagining implicit derivation (as it is today for no-associated-value enums). 
> However, now that I'm deeper into it (and have tried implementing some of 
> it), I think explicit is the way to go.
> 
> My main reason for changing my mind is that I think it will make the mutually 
> recursive cases much easier. Today, with implicit derivation, I have to 
> traverse the full cycles to figure out if equatability/hashability permeates 
> through the full type graph starting from a particular type. With explicit 
> derivation, I should just be able to look at the immediate member types to 
> see if they *declare* the conformance, and if it can't be derived (because a 
> stored property/associated value is not E/H), then it's an error on *that* 
> type.
> 
> My only reservations have been the inconsistency with no-associated-value 
> enums and raw value enums, where the derivation is currently implicit. But I 
> think the benefits of making it explicit outweigh the disadvantages.
> 
> Regarding syntax, some folks in the last discussion on this topic preferred a 
> "derived" keyword, but I feel that's unnecessary, and if Codable provides 
> precedent for not having such a keyword, we should stick with that.

Huge +1 to this proposal and +1 to making it explicit following the precedent 
set by Codable.  Thank you for driving this forward Tony!

In addition to the specific examples in the proposal I think it’s important to 
point out that this proposal will make it more feasible in general for 
libraries require Equatable or Hashable conformances of user-supplied types - 
doing so will no longer place the burden of manual conformance on all of these 
types.

It would be nice to see enums without associated values require explicit 
conformance as well in the future but that should be a separate proposal.

> 
> On Thu, May 4, 2017 at 3:16 PM Xiaodi Wu via swift-evolution 
> > wrote:
> I'm imagining no syntax; effectively, as though there exists an "extension 
> Equatable where [ all members : Equatable ]" with a default implementation.
> 
> 
> On Thu, May 4, 2017 at 17:13 John McCall  > wrote:
>> On May 4, 2017, at 6:10 PM, Andrew Bennett via swift-evolution 
>> > wrote:
>> I agree, let's make it opt-in.
>> 
>> This looks really great, I'm excited to get generated conformance for 
>> Equatable/Hashable in time for Swift 4.
>> 
>> I think it's worth mentioning that Encoding/Decoding generated conformance 
>> is already accepted and implemented in Swift 4. The implementation and 
>> acceptance criterion for Equatable/Hashable is likely to be very similar.
>> 
>> For the open questions, I think for the sake of getting this into Swift 4 we 
>> should go for explicit derivation, and don't allow omission of fields (yet).
> 
> Is there a syntax proposal for explicit derivation?  Or are you imagining 
> that just declaring the conformance but failing to implement it should 
> trigger derivation?
> 
> John.
> 
>> 
>> Omission is nice-to-have, but likely to be a long-winded bike-shed.
>> 
>> Changing from explicit to implicit is a loss of information, and has a large 
>> impact on the language, it can't easily be undone, so it requires a large 
>> discussion when it's decided. It only adds a little additional convenience 
>> to the user though.
>> 
>> I suggest we discuss implicit generation and allowing omission with 
>> follow-up proposals, they will very likely be additive non-breaking changes. 
>> For this proposal we play it safe and stick to explicit conformance and no 
>> omission of fields.
>> 
>> 
>> On Fri, May 5, 2017 at 8:01 AM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> Hmm, I can see the appeal of automatically deriving Equatable and Hashable 
>> conformance, but I'd like that to be opt-in. That is, types should declare 
>> that they are Equatable or Hashable to begin with. It wouldn't have to take 
>> extra syntax, as compiler magic could effectively synthesize default 
>> implementations for == and/or hashValue when all members are themselves 
>> Equatable or Hashable, respectively. With such a scheme, consideration can 
>> be made to accommodating classes too.
>> On Thu, May 4, 2017 at 15:37 Tony Allevato via swift-evolution 
>> > wrote:
>> Hi all,
>> 
>> A conversation on Twitter last night brought up some interest in this 
>> feature and I was encouraged to revive this proposal.
>> 
>> Jordan Rose mentioned 
>>  on Twitter that it 
>> could possibly make it in by the Swift 4 

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

[Tony Allevato via swift-evolution]

When I initially wrote an earlier version of this proposal last year, I was
imagining implicit derivation (as it is today for no-associated-value
enums). However, now that I'm deeper into it (and have tried implementing
some of it), I think explicit is the way to go.

My main reason for changing my mind is that I think it will make the
mutually recursive cases much easier. Today, with implicit derivation, I
have to traverse the full cycles to figure out if equatability/hashability
permeates through the full type graph starting from a particular type. With
explicit derivation, I should just be able to look at the immediate member
types to see if they *declare* the conformance, and if it can't be derived
(because a stored property/associated value is not E/H), then it's an error
on *that* type.

My only reservations have been the inconsistency with no-associated-value
enums and raw value enums, where the derivation is currently implicit. But
I think the benefits of making it explicit outweigh the disadvantages.

Regarding syntax, some folks in the last discussion on this topic preferred
a "derived" keyword, but I feel that's unnecessary, and if Codable provides
precedent for not having such a keyword, we should stick with that.

On Thu, May 4, 2017 at 3:16 PM Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> I'm imagining no syntax; effectively, as though there exists an "extension
> Equatable where [ all members : Equatable ]" with a default implementation.
>
>
> On Thu, May 4, 2017 at 17:13 John McCall  wrote:
>
>> On May 4, 2017, at 6:10 PM, Andrew Bennett via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> I agree, let's make it opt-in.
>>
>> This looks really great, I'm excited to get generated conformance for
>> Equatable/Hashable in time for Swift 4.
>>
>> I think it's worth mentioning that Encoding/Decoding generated
>> conformance is already accepted and implemented in Swift 4. The
>> implementation and acceptance criterion for Equatable/Hashable is likely to
>> be very similar.
>>
>> *For the open questions*, I think for the sake of getting this into
>> Swift 4 we should go for explicit derivation, and don't allow omission of
>> fields (yet).
>>
>>
>> Is there a syntax proposal for explicit derivation?  Or are you imagining
>> that just declaring the conformance but failing to implement it should
>> trigger derivation?
>>
>> John.
>>
>>
>> Omission is nice-to-have, but likely to be a long-winded bike-shed.
>>
>> Changing from explicit to implicit is a loss of information, and has a
>> large impact on the language, it can't easily be undone, so it requires a
>> large discussion when it's decided. It only adds a little additional
>> convenience to the user though.
>>
>> I suggest we discuss implicit generation and allowing omission with
>> follow-up proposals, they will very likely be additive non-breaking
>> changes. For this proposal we play it safe and stick to explicit
>> conformance and no omission of fields.
>>
>>
>> On Fri, May 5, 2017 at 8:01 AM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Hmm, I can see the appeal of automatically deriving Equatable and
>>> Hashable conformance, but I'd like that to be opt-in. That is, types should
>>> declare that they are Equatable or Hashable to begin with. It wouldn't have
>>> to take extra syntax, as compiler magic could effectively synthesize
>>> default implementations for == and/or hashValue when all members are
>>> themselves Equatable or Hashable, respectively. With such a scheme,
>>> consideration can be made to accommodating classes too.
>>> On Thu, May 4, 2017 at 15:37 Tony Allevato via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 Hi all,

 A conversation on Twitter last night brought up some interest in this
 feature and I was encouraged to revive this proposal.

 Jordan Rose mentioned
  on Twitter
 that it could possibly make it in by the Swift 4 deadline if others
 contributed—I have a WIP branch (albeit not currently working because I
 rebased after a couple months of it being idle) that does the work for
 enums but I got stuck on the mutually recursive cases. If this got
 approved, I'd love to collaborate with other interested folks to finish up
 the implementation.

 Link: https://gist.github.com/allevato/2fd10290bfa84accfbe977d8ac07daad


 Deriving Equatable and Hashable for value types

- Proposal: SE-

 
- Author(s): Tony Allevato 
- Status: Awaiting review

 
- Review manager: TBD


 

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

[Andrew Bennett via swift-evolution]

That's correct, consistent with Encoding/Decoding (SE-0166
)
it is sufficient to just do this:

struct MyType: Hashable {

  var foo: Int

  var bar: Float

}


Now MyType should get a generated implementation because each member is
also Hashable.


There's more details in the proposal near:

> An enum T that derives Equatable will receive a compiler-generated
> implementation of




On Fri, May 5, 2017 at 8:15 AM, Xiaodi Wu  wrote:

> I'm imagining no syntax; effectively, as though there exists an "extension
> Equatable where [ all members : Equatable ]" with a default implementation.
>
>
> On Thu, May 4, 2017 at 17:13 John McCall  wrote:
>
>> On May 4, 2017, at 6:10 PM, Andrew Bennett via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> I agree, let's make it opt-in.
>>
>> This looks really great, I'm excited to get generated conformance for
>> Equatable/Hashable in time for Swift 4.
>>
>> I think it's worth mentioning that Encoding/Decoding generated
>> conformance is already accepted and implemented in Swift 4. The
>> implementation and acceptance criterion for Equatable/Hashable is likely to
>> be very similar.
>>
>> *For the open questions*, I think for the sake of getting this into
>> Swift 4 we should go for explicit derivation, and don't allow omission of
>> fields (yet).
>>
>>
>> Is there a syntax proposal for explicit derivation?  Or are you imagining
>> that just declaring the conformance but failing to implement it should
>> trigger derivation?
>>
>> John.
>>
>>
>> Omission is nice-to-have, but likely to be a long-winded bike-shed.
>>
>> Changing from explicit to implicit is a loss of information, and has a
>> large impact on the language, it can't easily be undone, so it requires a
>> large discussion when it's decided. It only adds a little additional
>> convenience to the user though.
>>
>> I suggest we discuss implicit generation and allowing omission with
>> follow-up proposals, they will very likely be additive non-breaking
>> changes. For this proposal we play it safe and stick to explicit
>> conformance and no omission of fields.
>>
>>
>> On Fri, May 5, 2017 at 8:01 AM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Hmm, I can see the appeal of automatically deriving Equatable and
>>> Hashable conformance, but I'd like that to be opt-in. That is, types should
>>> declare that they are Equatable or Hashable to begin with. It wouldn't have
>>> to take extra syntax, as compiler magic could effectively synthesize
>>> default implementations for == and/or hashValue when all members are
>>> themselves Equatable or Hashable, respectively. With such a scheme,
>>> consideration can be made to accommodating classes too.
>>> On Thu, May 4, 2017 at 15:37 Tony Allevato via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 Hi all,

 A conversation on Twitter last night brought up some interest in this
 feature and I was encouraged to revive this proposal.

 Jordan Rose mentioned
  on Twitter
 that it could possibly make it in by the Swift 4 deadline if others
 contributed—I have a WIP branch (albeit not currently working because I
 rebased after a couple months of it being idle) that does the work for
 enums but I got stuck on the mutually recursive cases. If this got
 approved, I'd love to collaborate with other interested folks to finish up
 the implementation.

 Link: https://gist.github.com/allevato/2fd10290bfa84accfbe977d8ac07daad


 Deriving Equatable and Hashable for value types

- Proposal: SE-

 
- Author(s): Tony Allevato 
- Status: Awaiting review

 
- Review manager: TBD


 
 Introduction

 Value types are prevalent throughout the Swift language, and we
 encourage developers to think in those terms when writing their own types.
 Frequently, developers have to write large amounts of boilerplate code to
 support equatability and hashability of value types. This proposal offers a
 way for the compiler to automatically derive conformance to Equatable
 and Hashable to reduce this boilerplate, in a subset of scenarios
 where generating the correct implementation is known to be possible.

 Swift-evolution thread: Universal Equatability, Hashability, and
 Comparability
 

 

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

[Xiaodi Wu via swift-evolution]

I should add, requiring opt-in doesn't necessarily mean one must break
source compatibility for enums currently with derived equality. That can be
grandfathered in.

Later, we can even explore more comprehensive functionality when an enum is
declared "Foo : Int". In my opinion, the ideal endpoint in Swift N (where N
>> 4) is true value subtyping; absent that, it would only make sense that
Foo would at least conform to all the protocols to which Int conforms. A
longer-term discussion clearly out of scope here, but mentioned only to say
that existing magic doesn't need to be rolled back necessarily.

While we're on this topic though, it'd be really nice to revisit Equatable
and Hashable for tuples; that's one place where implicit magic may be the
best way to go. Currently, tuples of arity 6 or less benefit from a manual
hack to be Equatable, but we can clearly do better.

On Thu, May 4, 2017 at 17:01 Xiaodi Wu  wrote:

> Hmm, I can see the appeal of automatically deriving Equatable and Hashable
> conformance, but I'd like that to be opt-in. That is, types should declare
> that they are Equatable or Hashable to begin with. It wouldn't have to take
> extra syntax, as compiler magic could effectively synthesize default
> implementations for == and/or hashValue when all members are themselves
> Equatable or Hashable, respectively. With such a scheme, consideration can
> be made to accommodating classes too.
> On Thu, May 4, 2017 at 15:37 Tony Allevato via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Hi all,
>>
>> A conversation on Twitter last night brought up some interest in this
>> feature and I was encouraged to revive this proposal.
>>
>> Jordan Rose mentioned
>>  on Twitter that
>> it could possibly make it in by the Swift 4 deadline if others
>> contributed—I have a WIP branch (albeit not currently working because I
>> rebased after a couple months of it being idle) that does the work for
>> enums but I got stuck on the mutually recursive cases. If this got
>> approved, I'd love to collaborate with other interested folks to finish up
>> the implementation.
>>
>> Link: https://gist.github.com/allevato/2fd10290bfa84accfbe977d8ac07daad
>>
>>
>> Deriving Equatable and Hashable for value types
>>
>>- Proposal: SE-
>>
>> 
>>- Author(s): Tony Allevato 
>>- Status: Awaiting review
>>
>> 
>>- Review manager: TBD
>>
>>
>> 
>> Introduction
>>
>> Value types are prevalent throughout the Swift language, and we encourage
>> developers to think in those terms when writing their own types.
>> Frequently, developers have to write large amounts of boilerplate code to
>> support equatability and hashability of value types. This proposal offers a
>> way for the compiler to automatically derive conformance to Equatable and
>>  Hashable to reduce this boilerplate, in a subset of scenarios where
>> generating the correct implementation is known to be possible.
>>
>> Swift-evolution thread: Universal Equatability, Hashability, and
>> Comparability
>> 
>>
>> 
>> Motivation
>>
>> Building robust value types in Swift can involve writing significant
>> boilerplate code to support hashability and equatability. Equality is
>> pervasive across many value types, and for each one users must implement the
>>  == operator such that it performs a fairly rote memberwise equality
>> test. As an example, an equality test for a struct looks fairly
>> uninteresting:
>>
>> struct Foo: Equatable {
>>   static func == (lhs: Foo, rhs: Foo) -> Bool {
>> return lhs.property1 == rhs.property1 &&
>>lhs.property2 == rhs.property2 &&
>>lhs.property3 == rhs.property3 &&
>>...
>>   }
>> }
>>
>> What's worse is that this operator must be updated if any properties are
>> added, removed, or changed, and since it must be manually written, it's
>> possible to get it wrong, either by omission or typographical error.
>>
>> Likewise, hashability is necessary when one wishes to store a value type
>> in a Set or use one as a multi-valued Dictionary key. Writing
>> high-quality, well-distributed hash functions is not trivial so developers
>> may not put a great deal of thought into them – especially as the number of
>> properties increases – not realizing that their performance could
>> potentially suffer as a result. And as with equality, writing it manually
>> means there is the potential to get it wrong.
>>
>> In particular, the code that must be written to implement equality for
>> enums is quite verbose:
>>
>> 

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

[Xiaodi Wu via swift-evolution]

I'm imagining no syntax; effectively, as though there exists an "extension
Equatable where [ all members : Equatable ]" with a default implementation.


On Thu, May 4, 2017 at 17:13 John McCall  wrote:

> On May 4, 2017, at 6:10 PM, Andrew Bennett via swift-evolution <
> swift-evolution@swift.org> wrote:
> I agree, let's make it opt-in.
>
> This looks really great, I'm excited to get generated conformance for
> Equatable/Hashable in time for Swift 4.
>
> I think it's worth mentioning that Encoding/Decoding generated conformance
> is already accepted and implemented in Swift 4. The implementation and
> acceptance criterion for Equatable/Hashable is likely to be very similar.
>
> *For the open questions*, I think for the sake of getting this into Swift
> 4 we should go for explicit derivation, and don't allow omission of fields
> (yet).
>
>
> Is there a syntax proposal for explicit derivation?  Or are you imagining
> that just declaring the conformance but failing to implement it should
> trigger derivation?
>
> John.
>
>
> Omission is nice-to-have, but likely to be a long-winded bike-shed.
>
> Changing from explicit to implicit is a loss of information, and has a
> large impact on the language, it can't easily be undone, so it requires a
> large discussion when it's decided. It only adds a little additional
> convenience to the user though.
>
> I suggest we discuss implicit generation and allowing omission with
> follow-up proposals, they will very likely be additive non-breaking
> changes. For this proposal we play it safe and stick to explicit
> conformance and no omission of fields.
>
>
> On Fri, May 5, 2017 at 8:01 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Hmm, I can see the appeal of automatically deriving Equatable and
>> Hashable conformance, but I'd like that to be opt-in. That is, types should
>> declare that they are Equatable or Hashable to begin with. It wouldn't have
>> to take extra syntax, as compiler magic could effectively synthesize
>> default implementations for == and/or hashValue when all members are
>> themselves Equatable or Hashable, respectively. With such a scheme,
>> consideration can be made to accommodating classes too.
>> On Thu, May 4, 2017 at 15:37 Tony Allevato via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Hi all,
>>>
>>> A conversation on Twitter last night brought up some interest in this
>>> feature and I was encouraged to revive this proposal.
>>>
>>> Jordan Rose mentioned
>>>  on Twitter
>>> that it could possibly make it in by the Swift 4 deadline if others
>>> contributed—I have a WIP branch (albeit not currently working because I
>>> rebased after a couple months of it being idle) that does the work for
>>> enums but I got stuck on the mutually recursive cases. If this got
>>> approved, I'd love to collaborate with other interested folks to finish up
>>> the implementation.
>>>
>>> Link: https://gist.github.com/allevato/2fd10290bfa84accfbe977d8ac07daad
>>>
>>>
>>> Deriving Equatable and Hashable for value types
>>>
>>>- Proposal: SE-
>>>
>>> 
>>>- Author(s): Tony Allevato 
>>>- Status: Awaiting review
>>>
>>> 
>>>- Review manager: TBD
>>>
>>>
>>> 
>>> Introduction
>>>
>>> Value types are prevalent throughout the Swift language, and we
>>> encourage developers to think in those terms when writing their own types.
>>> Frequently, developers have to write large amounts of boilerplate code to
>>> support equatability and hashability of value types. This proposal offers a
>>> way for the compiler to automatically derive conformance to Equatable
>>> and Hashable to reduce this boilerplate, in a subset of scenarios where
>>> generating the correct implementation is known to be possible.
>>>
>>> Swift-evolution thread: Universal Equatability, Hashability, and
>>> Comparability
>>> 
>>>
>>> 
>>> Motivation
>>>
>>> Building robust value types in Swift can involve writing significant
>>> boilerplate code to support hashability and equatability. Equality is
>>> pervasive across many value types, and for each one users must implement the
>>>  == operator such that it performs a fairly rote memberwise equality
>>> test. As an example, an equality test for a struct looks fairly
>>> uninteresting:
>>>
>>> struct Foo: Equatable {
>>>   static func == (lhs: Foo, rhs: Foo) -> Bool {
>>> return lhs.property1 == rhs.property1 &&
>>>lhs.property2 == rhs.property2 &&
>>>lhs.property3 == rhs.property3 &&
>>>

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

[Andrew Bennett via swift-evolution]

I agree, let's make it opt-in.

This looks really great, I'm excited to get generated conformance for
Equatable/Hashable in time for Swift 4.

I think it's worth mentioning that Encoding/Decoding generated conformance
is already accepted and implemented in Swift 4. The implementation and
acceptance criterion for Equatable/Hashable is likely to be very similar.

*For the open questions*, I think for the sake of getting this into Swift 4
we should go for explicit derivation, and don't allow omission of fields
(yet).

Omission is nice-to-have, but likely to be a long-winded bike-shed.

Changing from explicit to implicit is a loss of information, and has a
large impact on the language, it can't easily be undone, so it requires a
large discussion when it's decided. It only adds a little additional
convenience to the user though.

I suggest we discuss implicit generation and allowing omission with
follow-up proposals, they will very likely be additive non-breaking
changes. For this proposal we play it safe and stick to explicit
conformance and no omission of fields.


On Fri, May 5, 2017 at 8:01 AM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> Hmm, I can see the appeal of automatically deriving Equatable and Hashable
> conformance, but I'd like that to be opt-in. That is, types should declare
> that they are Equatable or Hashable to begin with. It wouldn't have to take
> extra syntax, as compiler magic could effectively synthesize default
> implementations for == and/or hashValue when all members are themselves
> Equatable or Hashable, respectively. With such a scheme, consideration can
> be made to accommodating classes too.
> On Thu, May 4, 2017 at 15:37 Tony Allevato via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Hi all,
>>
>> A conversation on Twitter last night brought up some interest in this
>> feature and I was encouraged to revive this proposal.
>>
>> Jordan Rose mentioned
>>  on Twitter that
>> it could possibly make it in by the Swift 4 deadline if others
>> contributed—I have a WIP branch (albeit not currently working because I
>> rebased after a couple months of it being idle) that does the work for
>> enums but I got stuck on the mutually recursive cases. If this got
>> approved, I'd love to collaborate with other interested folks to finish up
>> the implementation.
>>
>> Link: https://gist.github.com/allevato/2fd10290bfa84accfbe977d8ac07daad
>>
>>
>> Deriving Equatable and Hashable for value types
>>
>>- Proposal: SE-
>>
>> 
>>- Author(s): Tony Allevato 
>>- Status: Awaiting review
>>
>> 
>>- Review manager: TBD
>>
>>
>> 
>> Introduction
>>
>> Value types are prevalent throughout the Swift language, and we encourage
>> developers to think in those terms when writing their own types.
>> Frequently, developers have to write large amounts of boilerplate code to
>> support equatability and hashability of value types. This proposal offers a
>> way for the compiler to automatically derive conformance to Equatable and
>>  Hashable to reduce this boilerplate, in a subset of scenarios where
>> generating the correct implementation is known to be possible.
>>
>> Swift-evolution thread: Universal Equatability, Hashability, and
>> Comparability
>> 
>>
>> 
>> Motivation
>>
>> Building robust value types in Swift can involve writing significant
>> boilerplate code to support hashability and equatability. Equality is
>> pervasive across many value types, and for each one users must implement the
>>  == operator such that it performs a fairly rote memberwise equality
>> test. As an example, an equality test for a struct looks fairly
>> uninteresting:
>>
>> struct Foo: Equatable {
>>   static func == (lhs: Foo, rhs: Foo) -> Bool {
>> return lhs.property1 == rhs.property1 &&
>>lhs.property2 == rhs.property2 &&
>>lhs.property3 == rhs.property3 &&
>>...
>>   }
>> }
>>
>> What's worse is that this operator must be updated if any properties are
>> added, removed, or changed, and since it must be manually written, it's
>> possible to get it wrong, either by omission or typographical error.
>>
>> Likewise, hashability is necessary when one wishes to store a value type
>> in a Set or use one as a multi-valued Dictionary key. Writing
>> high-quality, well-distributed hash functions is not trivial so developers
>> may not put a great deal of thought into them – especially as the number of
>> properties increases – not realizing that their performance could
>> 

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

[Xiaodi Wu via swift-evolution]

Hmm, I can see the appeal of automatically deriving Equatable and Hashable
conformance, but I'd like that to be opt-in. That is, types should declare
that they are Equatable or Hashable to begin with. It wouldn't have to take
extra syntax, as compiler magic could effectively synthesize default
implementations for == and/or hashValue when all members are themselves
Equatable or Hashable, respectively. With such a scheme, consideration can
be made to accommodating classes too.
On Thu, May 4, 2017 at 15:37 Tony Allevato via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi all,
>
> A conversation on Twitter last night brought up some interest in this
> feature and I was encouraged to revive this proposal.
>
> Jordan Rose mentioned
>  on Twitter that
> it could possibly make it in by the Swift 4 deadline if others
> contributed—I have a WIP branch (albeit not currently working because I
> rebased after a couple months of it being idle) that does the work for
> enums but I got stuck on the mutually recursive cases. If this got
> approved, I'd love to collaborate with other interested folks to finish up
> the implementation.
>
> Link: https://gist.github.com/allevato/2fd10290bfa84accfbe977d8ac07daad
>
>
> Deriving Equatable and Hashable for value types
>
>- Proposal: SE-
>
> 
>- Author(s): Tony Allevato 
>- Status: Awaiting review
>
> 
>- Review manager: TBD
>
>
> 
> Introduction
>
> Value types are prevalent throughout the Swift language, and we encourage
> developers to think in those terms when writing their own types.
> Frequently, developers have to write large amounts of boilerplate code to
> support equatability and hashability of value types. This proposal offers a
> way for the compiler to automatically derive conformance to Equatable and
> Hashable to reduce this boilerplate, in a subset of scenarios where
> generating the correct implementation is known to be possible.
>
> Swift-evolution thread: Universal Equatability, Hashability, and
> Comparability
> 
>
> 
> Motivation
>
> Building robust value types in Swift can involve writing significant
> boilerplate code to support hashability and equatability. Equality is
> pervasive across many value types, and for each one users must implement the
>  == operator such that it performs a fairly rote memberwise equality
> test. As an example, an equality test for a struct looks fairly
> uninteresting:
>
> struct Foo: Equatable {
>   static func == (lhs: Foo, rhs: Foo) -> Bool {
> return lhs.property1 == rhs.property1 &&
>lhs.property2 == rhs.property2 &&
>lhs.property3 == rhs.property3 &&
>...
>   }
> }
>
> What's worse is that this operator must be updated if any properties are
> added, removed, or changed, and since it must be manually written, it's
> possible to get it wrong, either by omission or typographical error.
>
> Likewise, hashability is necessary when one wishes to store a value type
> in a Set or use one as a multi-valued Dictionary key. Writing
> high-quality, well-distributed hash functions is not trivial so developers
> may not put a great deal of thought into them – especially as the number of
> properties increases – not realizing that their performance could
> potentially suffer as a result. And as with equality, writing it manually
> means there is the potential to get it wrong.
>
> In particular, the code that must be written to implement equality for
> enums is quite verbose:
>
> enum Token: Equatable {
>   case string(String)
>   case number(Int)
>   case lparen
>   case rparen
>
>   static func == (lhs: Token, rhs: Token) -> Bool {
> switch (lhs, rhs) {
> case (.string(let lhsString), .string(let rhsString)):
>   return lhsString == rhsString
> case (.number(let lhsNumber), .number(let lhsNumber)):
>   return lhsNumber == rhsNumber
> case (.lparen, .lparen), (.rparen, .rparen):
>   return true
> default:
>   return false
> }
>   }
> }
>
> Crafting a high-quality hash function for this enum would be similarly
> inconvenient to write.
>
> Swift already derives Equatable and Hashable conformance for a small
> subset of enums: those for which the cases have no associated values
> (including enums with raw types). Two instances of such an enum are equal
> if they are the same case, and an instance's hash value is its ordinal:
>
> enum Foo  {
>   case zero, one, two
> }
> let x = (Foo.one == Foo.two)  // evaluates to falselet y = Foo.one.hashValue  
>// evaluates to 1
>
> 

[swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

[Tony Allevato via swift-evolution]

Hi all,

A conversation on Twitter last night brought up some interest in this
feature and I was encouraged to revive this proposal.

Jordan Rose mentioned
 on Twitter that it
could possibly make it in by the Swift 4 deadline if others contributed—I
have a WIP branch (albeit not currently working because I rebased after a
couple months of it being idle) that does the work for enums but I got
stuck on the mutually recursive cases. If this got approved, I'd love to
collaborate with other interested folks to finish up the implementation.

Link: https://gist.github.com/allevato/2fd10290bfa84accfbe977d8ac07daad


Deriving Equatable and Hashable for value types

   - Proposal: SE-
   
   - Author(s): Tony Allevato 
   - Status: Awaiting review
   
   - Review manager: TBD


Introduction

Value types are prevalent throughout the Swift language, and we encourage
developers to think in those terms when writing their own types.
Frequently, developers have to write large amounts of boilerplate code to
support equatability and hashability of value types. This proposal offers a
way for the compiler to automatically derive conformance to Equatable and
Hashable to reduce this boilerplate, in a subset of scenarios where
generating the correct implementation is known to be possible.

Swift-evolution thread: Universal Equatability, Hashability, and
Comparability 

Motivation

Building robust value types in Swift can involve writing significant
boilerplate code to support hashability and equatability. Equality is
pervasive across many value types, and for each one users must implement the
 == operator such that it performs a fairly rote memberwise equality test.
As an example, an equality test for a struct looks fairly uninteresting:

struct Foo: Equatable {
  static func == (lhs: Foo, rhs: Foo) -> Bool {
return lhs.property1 == rhs.property1 &&
   lhs.property2 == rhs.property2 &&
   lhs.property3 == rhs.property3 &&
   ...
  }
}

What's worse is that this operator must be updated if any properties are
added, removed, or changed, and since it must be manually written, it's
possible to get it wrong, either by omission or typographical error.

Likewise, hashability is necessary when one wishes to store a value type in
a Set or use one as a multi-valued Dictionary key. Writing high-quality,
well-distributed hash functions is not trivial so developers may not put a
great deal of thought into them – especially as the number of properties
increases – not realizing that their performance could potentially suffer
as a result. And as with equality, writing it manually means there is the
potential to get it wrong.

In particular, the code that must be written to implement equality for
enums is quite verbose:

enum Token: Equatable {
  case string(String)
  case number(Int)
  case lparen
  case rparen

  static func == (lhs: Token, rhs: Token) -> Bool {
switch (lhs, rhs) {
case (.string(let lhsString), .string(let rhsString)):
  return lhsString == rhsString
case (.number(let lhsNumber), .number(let lhsNumber)):
  return lhsNumber == rhsNumber
case (.lparen, .lparen), (.rparen, .rparen):
  return true
default:
  return false
}
  }
}

Crafting a high-quality hash function for this enum would be similarly
inconvenient to write.

Swift already derives Equatable and Hashable conformance for a small subset
of enums: those for which the cases have no associated values (including
enums with raw types). Two instances of such an enum are equal if they are
the same case, and an instance's hash value is its ordinal:

enum Foo  {
  case zero, one, two
}
let x = (Foo.one == Foo.two)  // evaluates to falselet y =
Foo.one.hashValue // evaluates to 1

Likewise, conformance to RawRepresentable is automatically derived for
enums with a raw type. Since there is precedent for derived conformances in
Swift, we propose extending this support to more value types.
Proposed
solution

In general, we propose that value types derive conformance to Equatable/
Hashable if all of its members are Equatable/Hashable. We describe the
specific conditions under which these conformances are derived below,
followed by the details of how the conformance requirements are implemented.
Protocol
derivability conditions

For brevity, let P represent either the protocol 

Re: [swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

[Xiaodi Wu via swift-evolution]

The proposal looks good in general. Like some others, my chief concerns are
around dynamic enforcement. If it's not certain to be cheap enough to be
enabled without per-member opt-out and possibly build settings to turn it
off, perhaps the way to go is to add static enforcement now and prototype
what the cost will be for dynamic enforcement before designing all of these
knobs and switches.


On Tue, May 2, 2017 at 15:08 Ben Cohen via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of SE-0176: "Enforce Exclusive Access to Memory" begins now
> and runs through May 8, 2017.
>
> The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at:
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
> When replying, please try to keep the proposal link at the top of the
> message:
>
> Proposal link:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md
> Reply text
>
> Other replies
>
> 
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
>- What is your evaluation of the proposal?
>- Is the problem being addressed significant enough to warrant a
>change to Swift?
>- Does this proposal fit well with the feel and direction of Swift?
>- If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?
>- How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
> More information about the Swift evolution process is available at:
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thanks,
> Ben Cohen
> Review Manager
>
> ___
> 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] [Pitch] Enumerate from offset

[Ben Cohen via swift-evolution]

> On May 4, 2017, at 10:15 AM, Jaden Geller via swift-evolution 
>  wrote:
> 
> It's been suggested by a core team member that enumerated itself might not 
> hold its weight in the standard library. Instead, we ought to write 
> `zip(foo.indices, foo)` or `zip(0..., foo)`. It's easier for the caller to 
> see which side of the tuple stores the index and whether the index is an 
> integer or an actual index type. This use case seems to further support this 
> design since `zip(x…, foo)` and `zip(foo.indicies.drop(x), foo)` can be 
> easily written.
> 

Yup, this is my personal preference. Enumerated has a number of correctness and 
usability issues: slices aren’t zero based so you could miss a potential trap 
at runtime, order of the two arguments is unclear unlike the zip alternative, 
and it encourages people to write code using integers rather than indices even 
one the latter is more expressive and generalizes better if you ever want to 
make what you wrote generic.

Note also, since SE-0172 is now implemented on master, you can also write 
zip(6…, myArray) if you want to alter the starting value.

> On May 4, 2017, at 8:50 AM, BJ Homer via swift-evolution 
> > wrote:
> 
>> On May 4, 2017, at 8:51 AM, André Videla via swift-evolution 
>> > wrote:
>>> 
>>> You can do this trivially with drop. But enumerated from has one nice 
>>> property:
>>> 
>>> myArray.enumerated().dropFirst(6) // counts from 6
>>> 
>>> myArray.dropFirst(6).enumerated() // counts from 0
>>> 
>>> Those two lines do very different things even though they look similar
>> 
>> Neither of those does what the proposed enumerated(from:) does, if I 
>> understand correctly:
>> 
>> let a = [1, 2, 3, 4, 5]
>> let result = a.enumerated().dropFirst(2)
>> /*
>>  (offset: 2, element: 3)
>>  (offset: 3, element: 4)
>>  (offset: 4, element: 5)
>> 
>>  */
>> 
>> let result2 = a.dropFirst(2).enumerated()
>> /*
>>  (offset: 0, element: 3)
>>  (offset: 1, element: 4)
>>  (offset: 2, element: 5)
>>  */
>> 
>> 
>> let proposed = a.enumerated(from: 2)
>> /*
>>  (offset: 2, element: 1)
>>  (offset: 3, element: 2)
>>  (offset: 4, element: 3)
>>  (offset: 5, element: 4)
>>  (offset: 6, element: 5)
>>  */
>> The enumerated(from:) name is not clear; it reads (to me) like it’s going to 
>> enumerate elements starting at the Nth element. What it actually does (as 
>> proposed) is start counting at N, instead of counting at 0. 
>> 
>> I’m not convinced this is a valuable addition to the language. The use cases 
>> are not widely applicable, and if you need it it’s easy to get the same 
>> results in a way that avoids the confusion.
>> 
>> let a = [1, 2, 3, 4, 5]
>> 
>> let result = a.enumerated().map { (idx, element) in
>> return (idx+2, element)
>> }
>> 
>> // OR
>> 
>> for (idx, element) in a.enumerated() {
>> let offsetIndex = idx + 2
>> // Use offsetIndex how you will
>> }
>> 
>> 
>> -BJ
>> ___
>> 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] [Pitch] Enumerate from offset

[Jaden Geller via swift-evolution]

It's been suggested by a core team member that enumerated itself might not hold 
its weight in the standard library. Instead, we ought to write 
`zip(foo.indices, foo)` or `zip(0..., foo)`. It's easier for the caller to see 
which side of the tuple stores the index and whether the index is an integer or 
an actual index type. This use case seems to further support this design since 
`zip(x…, foo)` and `zip(foo.indicies.drop(x), foo)` can be easily written.

> On May 4, 2017, at 8:50 AM, BJ Homer via swift-evolution 
>  wrote:
> 
>> On May 4, 2017, at 8:51 AM, André Videla via swift-evolution 
>>  wrote:
>> 
>> You can do this trivially with drop. But enumerated from has one nice 
>> property:
>> 
>> myArray.enumerated().dropFirst(6) // counts from 6
>> 
>> myArray.dropFirst(6).enumerated() // counts from 0
>> 
>> Those two lines do very different things even though they look similar
> 
> Neither of those does what the proposed enumerated(from:) does, if I 
> understand correctly:
> 
> let a = [1, 2, 3, 4, 5]
> let result = a.enumerated().dropFirst(2)
> /*
>  (offset: 2, element: 3)
>  (offset: 3, element: 4)
>  (offset: 4, element: 5)
> 
>  */
> 
> let result2 = a.dropFirst(2).enumerated()
> /*
>  (offset: 0, element: 3)
>  (offset: 1, element: 4)
>  (offset: 2, element: 5)
>  */
> 
> 
> let proposed = a.enumerated(from: 2)
> /*
>  (offset: 2, element: 1)
>  (offset: 3, element: 2)
>  (offset: 4, element: 3)
>  (offset: 5, element: 4)
>  (offset: 6, element: 5)
>  */
> The enumerated(from:) name is not clear; it reads (to me) like it’s going to 
> enumerate elements starting at the Nth element. What it actually does (as 
> proposed) is start counting at N, instead of counting at 0. 
> 
> I’m not convinced this is a valuable addition to the language. The use cases 
> are not widely applicable, and if you need it it’s easy to get the same 
> results in a way that avoids the confusion.
> 
> let a = [1, 2, 3, 4, 5]
> 
> let result = a.enumerated().map { (idx, element) in
> return (idx+2, element)
> }
> 
> // OR
> 
> for (idx, element) in a.enumerated() {
> let offsetIndex = idx + 2
> // Use offsetIndex how you will
> }
> 
> 
> -BJ
> ___
> 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] [Pitch] Enumerate from offset

[BJ Homer via swift-evolution]

On May 4, 2017, at 8:51 AM, André Videla via swift-evolution 
 wrote:
> 
> You can do this trivially with drop. But enumerated from has one nice 
> property:
> 
> myArray.enumerated().dropFirst(6) // counts from 6
> 
> myArray.dropFirst(6).enumerated() // counts from 0
> 
> Those two lines do very different things even though they look similar

Neither of those does what the proposed enumerated(from:) does, if I understand 
correctly:

let a = [1, 2, 3, 4, 5]
let result = a.enumerated().dropFirst(2)
/*
 (offset: 2, element: 3)
 (offset: 3, element: 4)
 (offset: 4, element: 5)

 */

let result2 = a.dropFirst(2).enumerated()
/*
 (offset: 0, element: 3)
 (offset: 1, element: 4)
 (offset: 2, element: 5)
 */


let proposed = a.enumerated(from: 2)
/*
 (offset: 2, element: 1)
 (offset: 3, element: 2)
 (offset: 4, element: 3)
 (offset: 5, element: 4)
 (offset: 6, element: 5)
 */
The enumerated(from:) name is not clear; it reads (to me) like it’s going to 
enumerate elements starting at the Nth element. What it actually does (as 
proposed) is start counting at N, instead of counting at 0. 

I’m not convinced this is a valuable addition to the language. The use cases 
are not widely applicable, and if you need it it’s easy to get the same results 
in a way that avoids the confusion.

let a = [1, 2, 3, 4, 5]

let result = a.enumerated().map { (idx, element) in
return (idx+2, element)
}

// OR

for (idx, element) in a.enumerated() {
let offsetIndex = idx + 2
// Use offsetIndex how you will
}


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

Re: [swift-evolution] [Pitch] Enumerate from offset

[André Videla via swift-evolution]

You can do this trivially with drop. But enumerated from has one nice property:

myArray.enumerated().dropFirst(6) // counts from 6

myArray.dropFirst(6).enumerated() // counts from 0

Those two lines do very different things even though they look similar

myArray.enumerated(from: 6)
Is unambiguous 

But I don't think it is worth adding to the sequence protocol if the argument 
is that it's unambiguous. 

Andre Videla 

> On 4 May 2017, at 14:39, Pavol Vaskovic via swift-evolution 
>  wrote:
> 
> Hello!
> 
> Here's a pitch to pick a small nit from the Sequence protocol:
> 
> https://github.com/palimondo/swift-evolution/blob/sequence-cleanup/proposals/-enumerate-from.md
> 
> Best regards
> Pavol Vaskovic
> 
> Enumerate from offset
> 
> Proposal: SE-
> 
> Authors: Pavol Vaskovic, Author 2
> 
> Review Manager: TBD
> 
> Status: Pitch
> 
> Bugs: SR-4746
> 
> Introduction
> 
> Let user specify the staring index for enumerated method on Sequences.
> 
> Swift-evolution thread: Discussion thread topic for that proposal
> 
> Motivation
> 
> The enumerated() method defined in an extension on protocol Sequence always 
> counts from 0. When you need the numbers to be counting up from different 
> index, you have to post process the resulting tuple in an inconvenient way.
> 
> Proposed solution
> 
> We could provide an option to count elements from a user specified offset:
> 
> [6, 7, 8].enumerated(from: 6)
> // [(offset: 6, element: 6), (offset: 7, element: 7), (offset: 8, element: 8)]
> If implemented with default parameter, this does not change the usage for 
> existing code, being source compatible with Swift 3.
> 
> Detailed design
> 
> The proposed solution is to propagate the starting value to the internal 
> counter on EnumeratedIterator and set the default starting value to 0.
> 
> public struct EnumeratedIterator<
> Base : IteratorProtocol
> > : IteratorProtocol, Sequence {
> internal var _base: Base
> internal var _count: Int
> 
> /// Construct from a `Base` iterator.
> internal init(_base: Base, _offset: Int) {
> self._base = _base
> self._count = _offset
> }
> 
> /// The type of element returned by `next()`.
> public typealias Element = (offset: Int, element: Base.Element)
> 
> /// Advances to the next element and returns it, or `nil` if no next 
> element
> /// exists.
> ///
> /// Once `nil` has been returned, all subsequent calls return `nil`.
> public mutating func next() -> Element? {
> guard let b = _base.next() else { return nil }
> let result = (offset: _count, element: b)
> _count += 1
> return result
> }
> }
> 
> public struct EnumeratedSequence : Sequence {
> internal var _base: Base
> internal let _offset: Int
> 
> /// Construct from a `Base` sequence.
> internal init(_base: Base, _offset: Int) {
> self._base = _base
> self._offset = _offset
> }
> 
> /// Returns an iterator over the elements of this sequence.
> public func makeIterator() -> _EnumeratedIterator {
> return EnumeratedIterator(_base: _base.makeIterator(), _offset: 
> _offset)
> }
> }
> 
> extension Sequence {
> public func enumerated(from: Int = 0) -> _numeratedSequence {
> return EnumeratedSequence(_base: self, _offset: from)
> }
> }
> Source compatibility
> 
> Proposed change is source compatible with Swift 3.
> 
> Effect on ABI stability and resilience
> 
> This change does affect the ABI and should be implemented before we freeze it.
> 
> Alternatives considered
> 
> Currently proposed workaround for the lack of flexibility in enumerated() is 
> to use zip with the collection and half-open range. From SR-0172 One-sided 
> Ranges:
> 
> Additionally, when the index is a countable type, i... should form a Sequence 
> that counts up from i indefinitely. This is useful in forming variants of 
> Sequence.enumerated() when you either want them non-zero-based i.e.zip(1..., 
> greeting), or want to flip the order i.e. zip(greeting, 0...).
> Drawback of this approach is that you need to use free function zip, forcing 
> a break in the chain of sequence operations, as there is currently no zipped 
> method on Sequence.
> 
> If this is the preffered approach, we should consider removing the 
> enumerated() method altogether, because the limited usefullness in its 
> current state hardly justifies the space on API surface it occupies.
> ___
> 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] [Pitch] Enumerate from offset

[Pavol Vaskovic via swift-evolution]

Hello!

Here's a pitch to pick a small nit from the Sequence protocol:

https://github.com/palimondo/swift-evolution/blob/sequence-cleanup/proposals/-enumerate-from.md

Best regards
Pavol Vaskovic

Enumerate from offset

   -

   Proposal: SE-
   

   -

   Authors: Pavol Vaskovic , Author 2
   
   -

   Review Manager: TBD
   -

   Status: Pitch
   -

   Bugs: SR-4746 


Introduction

Let user specify the staring index for enumerated method on Sequences.

Swift-evolution thread: Discussion thread topic for that proposal


Motivation

The enumerated() method defined in an extension on protocol Sequence always
counts from 0. When you need the numbers to be counting up from different
index, you have to post process the resulting tuple in an inconvenient way.
Proposed
solution

We could provide an option to count elements from a user specified offset:

[6, 7, 8].enumerated(from: 6)// [(offset: 6, element: 6), (offset: 7,
element: 7), (offset: 8, element: 8)]

If implemented with default parameter, this does not change the usage for
existing code, being source compatible with Swift 3.
Detailed
design

The proposed solution is to propagate the starting value to the internal
counter on EnumeratedIterator and set the default starting value to 0.

public struct EnumeratedIterator<
Base : IteratorProtocol> : IteratorProtocol, Sequence {
internal var _base: Base
internal var _count: Int

/// Construct from a `Base` iterator.internal init(_base:
Base, _offset: Int) {
self._base = _base
self._count = _offset
}

/// The type of element returned by `next()`.public typealias
Element = (offset: Int, element: Base.Element)

/// Advances to the next element and returns it, or `nil` if no
next element/// exists.////// Once `nil` has been
returned, all subsequent calls return `nil`.public mutating func
next() -> Element? {
guard let b = _base.next() else { return nil }
let result = (offset: _count, element: b)
_count += 1
return result
}
}
public struct EnumeratedSequence : Sequence {
internal var _base: Base
internal let _offset: Int

/// Construct from a `Base` sequence.internal init(_base:
Base, _offset: Int) {
self._base = _base
self._offset = _offset
}

/// Returns an iterator over the elements of this sequence.
public func makeIterator() -> _EnumeratedIterator {
return EnumeratedIterator(_base: _base.makeIterator(), _offset: _offset)
}
}
extension Sequence {
public func enumerated(from: Int = 0) -> _numeratedSequence {
return EnumeratedSequence(_base: self, _offset: from)
}
}

Source
compatibility

Proposed change is source compatible with Swift 3.
Effect
on ABI stability and resilience

This change does affect the ABI and should be implemented before we freeze
it.
Alternatives
considered

Currently proposed workaround for the lack of flexibility in enumerated() is
to use zip with the collection and half-open range. From SR-0172 One-sided
Ranges

:

Additionally, when the index is a countable type, i... should form a
Sequence that counts up from i indefinitely. This is useful in forming
variants of Sequence.enumerated() when you either want them non-zero-based
i.e.zip(1..., greeting), or want to flip the order i.e. zip(greeting, 0...).

Drawback of this approach is that you need to use free function zip,
forcing a break in the chain of sequence operations, as there is currently
no zipped method on Sequence.

If this is the preffered approach, we should consider removing the
enumerated() method altogether, because the limited usefullness in its
current state hardly justifies the space on API surface it occupies.
___
swift-evolution 

Re: [swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

[Michel Fortin via swift-evolution]

> https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md

> What is your evaluation of the proposal?

It's a bit hard to evaluate without experience. But I would summarize the 
benefits like this:

1. Clearer semantics inside functions. Variables that can alias each other 
makes things hard to reason about. Generally, this we just disregard the 
possibility of this happening. Having the language guard against this is going 
to make it easier to reason about the effects of the code.

2. Better optimizations. Variable that can alias each other force the optimizer 
to be pessimistic. All that to support cases that probably weren't well though 
out when the code was written because the semantics are hard to follow.

I find the first point about clearer semantics most interesting.


> Is the problem being addressed significant enough to warrant a change to 
> Swift?

Looks like something that should be done. Swift already disallows that I think, 
but it only checks for the obvious cases.

Providing guaranties about exclusivity opens the road to a lot of useful things 
for future evolution of the language.


> Does this proposal fit well with the feel and direction of Swift?

Given that the alternative option to dynamic checking is to have a complex set 
of annotations to track everything statically, I think the proposed approach 
makes sense.

If I understand well however, allowing the optimizer to be more optimistic 
about exclusivity is going to be make memory corruption more likely in cases 
the exclusivity rule is violated for types that contain pointers. I'm thus a 
bit weary of the idea of disabling the runtime checks in production by default 
while at the same time enabling the optimizations that depends on this 
unverified exclusivity.


> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?

This reminds me of `restrict` in C, which can be dangerous if used incorrectly. 
Having a checking mechanism for exclusivity removes those concerns.
https://en.wikipedia.org/wiki/Restrict


> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

Read the ownership manifesto, the proposal, the discussion about the proposal.


-- 
Michel Fortin
https://michelf.ca

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