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

[Brent Royal-Gordon via swift-evolution]

Sorry for wrecking the threading, but any chance we could change the syntax to:

let (x myX: Int, y myY: Int) = ...

That would ensure the identifier after the colon was always treated as a type. 
I suppose if you wanted to infer the type, it'd be:

let (x myX, y myY) = ...

-- 
Brent Royal-Gordon
Sent from my iPhone

> On May 5, 2017, at 12:04 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> If we ban reordering now, than I don’t see choosing different names in tuple 
> destructuring as a strong argument of allowing labels there let (x: a, y: b). 
> They’re literally the same as one would write comments inside the 
> destructured tuple let (/* my x */ x, /* my y*/ y).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Omit deprecation warnings for same-file references

[Xiaodi Wu via swift-evolution]

The reason I suggest this is that the most consistent boundary with the
rest of Swift is the module. I don't doubt that some may wish to deprecate
features even for some subset of internal users, but it seems plainly
obvious to me that the more common scenario will be deprecating for public
consumption only.

Since you're presenting scenarios in which it might make sense to have
scope-based or file-based deprecation, then more fine tuning would be the
answer. Without that, I'd argue the default ought to be what I call "public
deprecated." The within-a-module use case should be the later addition.


On Fri, May 5, 2017 at 17:15 Tony Allevato  wrote:

> I'm inclined to agree. I'm not opposed outright to that degree of
> configurability but at the same time I wonder if the complexity is
> needed—it feels like it's getting close to the "fine-tuned auditing" that I
> argued against during the discussions about access control.
>
> It could also be done additively later, if a significant amount of people
> using the feature found that they did need it.
>
> On Fri, May 5, 2017 at 3:09 PM BJ Homer  wrote:
>
>>
>> > On May 5, 2017, at 1:34 PM, Xiaodi Wu  wrote:
>> >
>> > Why guess as to which of these is appropriate? Couldn't you support the
>> current and all variants of this behavior by allowing access modifiers on
>> 'deprecated'?
>> >
>> > * public deprecated: warning when used from a different module, behaves
>> as though there's a public deprecated pass-through
>> >
>> > * internal deprecated: warning when used from a different file
>> >
>> > * fileprivate deprecated: warning when used from a different scope
>> >
>> > * private deprecated: synonymous with deprecated for backwards
>> compatibility, behaves like it does today
>> >
>> > (No need for complicated parsing; SE-25 allows a higher nominal access
>> modifier inside a lower one without warning, so it's fine to allow 'public
>> deprecated' to decorate a private member with no effect.)
>>
>> I’m not opposed to more configurability like that. I worry it makes the
>> feature more complicated and potentially delays the acceptance or
>> implementation of this feature, though. If it’s easy to implement, though,
>> then sure, I like that.
>>
>> -BJ
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Omit deprecation warnings for same-file references

[Tony Allevato via swift-evolution]

On Fri, May 5, 2017 at 3:20 PM Tony Arnold  wrote:

> Hi Tony,
>
> > On 6 May 2017, at 04:12, Tony Allevato via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > These warnings are emitted for any reference to a deprecated entity,
> including those in the same file. In some cases, however, it may be
> necessary and correct to continue referring to the deprecated entity
> privately while discouraging its external use. In these scenarios, the
> warnings are superfluous and generate noise in the build logs. We propose
> eliminating these warnings for references made in the same file.
>
> If same file is the direction that the proposal is leaning toward, what’s
> stopping you from creating an internal (or private) implementation that’s
> not deprecated. You could then call that via the public, deprecated
> method/property?
>

Hi Tony, this is called out in the proposal :) In addition to the fact that
it requires writing boilerplate code manually and updating all references
to the deprecated property in type's implementation, there are performance
implications as well due to the change in memory management behavior. In
the example presented in the proposal:

Behaviorally, these are the same. However, the generated code is different
because the memory management semantics change due to the passthrough
property. With full optimizations on, useDirectHolder executes in 1.360 sec
while useIndirectHolder executes in 235.8 sec—over two orders of magnitude
slower!



> i.e.
>
> ```swift
> @available(*, deprecated, message: "use 'phoneNumbers' instead")
> public var phoneNumber: String? {
> get {
> return _phoneNumber
> }
> set {
> _phoneNumber = newValue
> }
> }
>
> private var _phoneNumber: String?
>
> ```
>
> Am I missing something that would prevent this from working?
>
> I can see that what you’re proposing would negate the need for the private
> backing property/method, but it seems like it’s introducing complexity for
> the few times you might need this.
>
> thanks,
>
>
> Tony
>
>
>
> --
> Tony Arnold
> +61 411 268 532 <+61%20411%20268%20532>
> http://thecocoabots.com/
>
> ABN: 14831833541
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Omit deprecation warnings for same-file references

[Tony Arnold via swift-evolution]

Hi Tony,

> On 6 May 2017, at 04:12, Tony Allevato via swift-evolution 
>  wrote:
> 
> These warnings are emitted for any reference to a deprecated entity, 
> including those in the same file. In some cases, however, it may be necessary 
> and correct to continue referring to the deprecated entity privately while 
> discouraging its external use. In these scenarios, the warnings are 
> superfluous and generate noise in the build logs. We propose eliminating 
> these warnings for references made in the same file.

If same file is the direction that the proposal is leaning toward, what’s 
stopping you from creating an internal (or private) implementation that’s not 
deprecated. You could then call that via the public, deprecated method/property?

i.e.

```swift
@available(*, deprecated, message: "use 'phoneNumbers' instead")
public var phoneNumber: String? {
get {
return _phoneNumber
}
set {
_phoneNumber = newValue
}
}

private var _phoneNumber: String?

```

Am I missing something that would prevent this from working?

I can see that what you’re proposing would negate the need for the private 
backing property/method, but it seems like it’s introducing complexity for the 
few times you might need this.

thanks,


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] Pitch: Omit deprecation warnings for same-file references

[Tony Allevato via swift-evolution]

I'm inclined to agree. I'm not opposed outright to that degree of
configurability but at the same time I wonder if the complexity is
needed—it feels like it's getting close to the "fine-tuned auditing" that I
argued against during the discussions about access control.

It could also be done additively later, if a significant amount of people
using the feature found that they did need it.

On Fri, May 5, 2017 at 3:09 PM BJ Homer  wrote:

>
> > On May 5, 2017, at 1:34 PM, Xiaodi Wu  wrote:
> >
> > Why guess as to which of these is appropriate? Couldn't you support the
> current and all variants of this behavior by allowing access modifiers on
> 'deprecated'?
> >
> > * public deprecated: warning when used from a different module, behaves
> as though there's a public deprecated pass-through
> >
> > * internal deprecated: warning when used from a different file
> >
> > * fileprivate deprecated: warning when used from a different scope
> >
> > * private deprecated: synonymous with deprecated for backwards
> compatibility, behaves like it does today
> >
> > (No need for complicated parsing; SE-25 allows a higher nominal access
> modifier inside a lower one without warning, so it's fine to allow 'public
> deprecated' to decorate a private member with no effect.)
>
> I’m not opposed to more configurability like that. I worry it makes the
> feature more complicated and potentially delays the acceptance or
> implementation of this feature, though. If it’s easy to implement, though,
> then sure, I like that.
>
> -BJ
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Omit deprecation warnings for same-file references

[BJ Homer via swift-evolution]

> On May 5, 2017, at 1:34 PM, Xiaodi Wu  wrote:
> 
> Why guess as to which of these is appropriate? Couldn't you support the 
> current and all variants of this behavior by allowing access modifiers on 
> 'deprecated'?
> 
> * public deprecated: warning when used from a different module, behaves as 
> though there's a public deprecated pass-through
> 
> * internal deprecated: warning when used from a different file
> 
> * fileprivate deprecated: warning when used from a different scope
> 
> * private deprecated: synonymous with deprecated for backwards compatibility, 
> behaves like it does today
> 
> (No need for complicated parsing; SE-25 allows a higher nominal access 
> modifier inside a lower one without warning, so it's fine to allow 'public 
> deprecated' to decorate a private member with no effect.)

I’m not opposed to more configurability like that. I worry it makes the feature 
more complicated and potentially delays the acceptance or implementation of 
this feature, though. If it’s easy to implement, though, then sure, I like that.

-BJ
___
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]

It would have to be compiler magic. If I recall, the only factor preventing
it is that no one has implemented it, but one of the core team members has
noted that it should be fairly straightforward. I don't have the time right
now or I'd seriously take a stab at it.


On Fri, May 5, 2017 at 14:20 Tony Allevato  wrote:

> On Fri, May 5, 2017 at 12:18 PM Xiaodi Wu  wrote:
>
>> Hmm, with these complications, I regret suggesting that this could be
>> extended to classes so easily. Definitely some interesting solutions, but
>> my inclination as well would be to leave classes out entirely for the
>> moment and let it percolate for Swift 4.1+. After all, it's an additive
>> convenience.
>>
>> Any thought as to including tuples though?
>>
>
> Can non-nominal types conform to protocols? I thought that was the main
> limitation for supporting these conformances on tuples.
>
> I would love to support them if possible to get rid of the arbitrary ==
> implementations in the standard library and make multi-component dictionary
> keys easier to work with, but my understanding was that the above issue was
> the bigger factor preventing it.
>
>
>
>
>> On Fri, May 5, 2017 at 13:51 Matthew Johnson via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> On May 5, 2017, at 1:33 PM, Tony Allevato 
>>> wrote:
>>>
>>>
>>>
>>> On Fri, May 5, 2017 at 11:07 AM Matthew Johnson 
>>> wrote:
>>>
 On May 5, 2017, at 10:45 AM, Tony Allevato via swift-evolution <
 swift-evolution@swift.org> wrote:

 Thanks for your feedback, everybody!


 Thanks for continuing to drive this forward!


 I've updated the gist
  to
 reflect what seems to be a consensus here:

 * Derived conformances are now opt-in (this makes the recursive case
 *much* cleaner, and the complexity involved in that section has been
 completely removed)


 Can the opt-in conformance be declared in an extension?  If so, can the
 extension be in a different module than the original declaration?  If so,
 do you intend any restrictions, such as requiring all members of the type
 declared in a different module to be public?  My initial thought is that
 this should be possible as long as all members are visible.

>>>
>>> Declaring the conformance in an extension in the same module should
>>> definitely be allowed; I believe this would currently be the only way to
>>> support conditional conformances (such as the `Optional: Hashable where
>>> Wrapped: Hashable` example in the updated draft), without requiring deeper
>>> syntactic changes.
>>>
>>> I'm less sure about conformances being added in other modules, but I'm
>>> inclined to agree with your assessment. I could see two ways of
>>> interpreting it:
>>>
>>> * E/H can only be derived in an extension in an external module if all
>>> the members are accessible (and the other conditions are met).
>>> * E/H can be derived in an extension in an external module using only
>>> the subset of accessible members (if the other conditions are met).
>>>
>>> These are subtly different. The argument for the first would be "if you
>>> want to add E/H to a type in a different module, you must *consciously*
>>> decide which members you want to use in those computations". The argument
>>> for the second would be "you can already make a type in a different module
>>> conform to E/H and you'd be restricted to the accessible members there, so
>>> let's make that path easier for users too."
>>>
>>> The first case is probably the safer choice. I'm not sure about the
>>> implementation difficulty of each.
>>>
>>>
 * Classes are supported now as well

 Please take a look at the updated version and let me know if there are
 any concerns! If folks like it, I'll prepare a pull request.


 Will the synthesis for classes dispatch through a non-final method
 which is expected to be overridden by subclasses?  You don’t explicitly
 state this but it seems implied.  If so, what if  the subclass requires a
 custom implementation?  This would require the signature of the non-final
 method to be part of the synthesis contract.

>>>
 Supporting non-final classes introduces enough complexity (especially
 when multiple modules are involved).  I would hate to see it get
 sidetracked in discussions regarding non-final classes and miss the Swift 4
 window because of that.  Given the limited time left for Swift 4 it might
 be better to keep the initial proposal simpler and consider a followup in
 the Swift 5 timeframe to build on the initial proposal.

>>>
>>> For ==, the operator must already be "class final" or "static"
>>> regardless of this proposal, and it can't be "overridden" as such in
>>> subclasses because the arguments would be 

Re: [swift-evolution] Pitch: Omit deprecation warnings for same-file references

[Xiaodi Wu via swift-evolution]

Why guess as to which of these is appropriate? Couldn't you support the
current and all variants of this behavior by allowing access modifiers on
'deprecated'?

* public deprecated: warning when used from a different module, behaves as
though there's a public deprecated pass-through

* internal deprecated: warning when used from a different file

* fileprivate deprecated: warning when used from a different scope

* private deprecated: synonymous with deprecated for backwards
compatibility, behaves like it does today

(No need for complicated parsing; SE-25 allows a higher nominal access
modifier inside a lower one without warning, so it's fine to allow 'public
deprecated' to decorate a private member with no effect.)

On Fri, May 5, 2017 at 13:51 Tony Allevato via swift-evolution <
swift-evolution@swift.org> wrote:

> On Fri, May 5, 2017 at 11:37 AM BJ Homer  wrote:
>
>> I’ve run into this problem as well, when dealing with legacy file formats
>> (similar to the example in the proposal), and I agree it would be nice to
>> be able to address it. We’ve got a few “permanent” warnings in our code
>> base right now due to this. I’m not sure whether the deprecation should be
>> disabled for the entire file, though; perhaps it should be disabled just
>> within the type itself? I don’t know how that would contribute to the
>> complexity of the implementation, but it seems like we would still want to
>> warn about deprecated accesses between two types declared in the same file.
>>
>
> I initially picked "same file" because (1) it appears to be dead simple to
> implement and (2) the idea that if someone is marking a definition as
> private in a file, they can easily go through the same file and resolve any
> uses of that declaration if they no longer want them. But it's possible
> that there are helper types that just happen to be in the same file where
> you'd like to be warned about using those "privately allowed APIs", so
> you're right that same-file suppression would make those harder to detect.
>
> Given that, I'd be open to either of these possibilities and I'd love to
> hear what others think:
>
> * Give deprecation-suppression "fileprivate" semantics
> * Give deprecation-suppression "private" semantics (suppressed in the same
> type and in extensions of that type within the same file)
>
>
>
>
>> -BJ Homer
>>
>> On May 5, 2017, at 12:12 PM, Tony Allevato via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Hey Swift Evolvers,
>>
>> I'd like to propose a change that would suppress deprecation warnings
>> when the reference to the deprecated declaration is in the same file as
>> that declaration.
>>
>> This personally affects one of my projects (Swift protocol buffers)
>> because .proto files allow declarations to be declared as deprecated, and
>> we'd like to surface that by deprecating the equivalent declaration in the
>> Swift code that we generate. We can't do this without generating noisy
>> build logs, because we still need to reference the deprecated declarations
>> to encode/decode the messages correctly; and the workarounds have
>> significant performance penalties as described in the draft.
>>
>> I'd love some feedback from folks to know whether this—or something like
>> it—is something that seems desirable/undesirable for the language. I've
>> tinkered with an implementation in a branch
>> 
>> and it's fairly straightforward.
>>
>> Gist link:
>> https://gist.github.com/allevato/76f098a761147f3be5017d10a6f4ecbb
>>
>>
>> Omit deprecation warnings for same-file references
>>
>>- Proposal: SE-
>>
>> 
>>- Author(s): Tony Allevato 
>>- Status: Awaiting review
>>
>> 
>>- Review manager: TBD
>>
>>
>> 
>> Introduction
>>
>> Public API developers can use the @available attribute in Swift to mark
>> APIs as deprecated, which will emit warnings when a user references that
>> API to notify them that that particular API is no longer preferred or may
>> disappear in the future.
>>
>> These warnings are emitted for *any* reference to a deprecated entity,
>> including those in the same file. In some cases, however, it may be
>> necessary and correct to continue referring to the deprecated entity
>> privately while discouraging its external use. In these scenarios, the
>> warnings are superfluous and generate noise in the build logs. We propose
>> eliminating these warnings for references made in the same file.
>>
>> Swift-evolution thread: TBD
>> 
>>
>> 
>> Motivation
>>
>> As APIs 

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

[Tony Allevato via swift-evolution]

On Fri, May 5, 2017 at 12:18 PM Xiaodi Wu  wrote:

> Hmm, with these complications, I regret suggesting that this could be
> extended to classes so easily. Definitely some interesting solutions, but
> my inclination as well would be to leave classes out entirely for the
> moment and let it percolate for Swift 4.1+. After all, it's an additive
> convenience.
>
> Any thought as to including tuples though?
>

Can non-nominal types conform to protocols? I thought that was the main
limitation for supporting these conformances on tuples.

I would love to support them if possible to get rid of the arbitrary ==
implementations in the standard library and make multi-component dictionary
keys easier to work with, but my understanding was that the above issue was
the bigger factor preventing it.




> On Fri, May 5, 2017 at 13:51 Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On May 5, 2017, at 1:33 PM, Tony Allevato 
>> wrote:
>>
>>
>>
>> On Fri, May 5, 2017 at 11:07 AM Matthew Johnson 
>> wrote:
>>
>>> On May 5, 2017, at 10:45 AM, Tony Allevato via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> Thanks for your feedback, everybody!
>>>
>>>
>>> Thanks for continuing to drive this forward!
>>>
>>>
>>> I've updated the gist
>>>  to
>>> reflect what seems to be a consensus here:
>>>
>>> * Derived conformances are now opt-in (this makes the recursive case
>>> *much* cleaner, and the complexity involved in that section has been
>>> completely removed)
>>>
>>>
>>> Can the opt-in conformance be declared in an extension?  If so, can the
>>> extension be in a different module than the original declaration?  If so,
>>> do you intend any restrictions, such as requiring all members of the type
>>> declared in a different module to be public?  My initial thought is that
>>> this should be possible as long as all members are visible.
>>>
>>
>> Declaring the conformance in an extension in the same module should
>> definitely be allowed; I believe this would currently be the only way to
>> support conditional conformances (such as the `Optional: Hashable where
>> Wrapped: Hashable` example in the updated draft), without requiring deeper
>> syntactic changes.
>>
>> I'm less sure about conformances being added in other modules, but I'm
>> inclined to agree with your assessment. I could see two ways of
>> interpreting it:
>>
>> * E/H can only be derived in an extension in an external module if all
>> the members are accessible (and the other conditions are met).
>> * E/H can be derived in an extension in an external module using only the
>> subset of accessible members (if the other conditions are met).
>>
>> These are subtly different. The argument for the first would be "if you
>> want to add E/H to a type in a different module, you must *consciously*
>> decide which members you want to use in those computations". The argument
>> for the second would be "you can already make a type in a different module
>> conform to E/H and you'd be restricted to the accessible members there, so
>> let's make that path easier for users too."
>>
>> The first case is probably the safer choice. I'm not sure about the
>> implementation difficulty of each.
>>
>>
>>> * Classes are supported now as well
>>>
>>> Please take a look at the updated version and let me know if there are
>>> any concerns! If folks like it, I'll prepare a pull request.
>>>
>>>
>>> Will the synthesis for classes dispatch through a non-final method which
>>> is expected to be overridden by subclasses?  You don’t explicitly state
>>> this but it seems implied.  If so, what if  the subclass requires a custom
>>> implementation?  This would require the signature of the non-final method
>>> to be part of the synthesis contract.
>>>
>>
>>> Supporting non-final classes introduces enough complexity (especially
>>> when multiple modules are involved).  I would hate to see it get
>>> sidetracked in discussions regarding non-final classes and miss the Swift 4
>>> window because of that.  Given the limited time left for Swift 4 it might
>>> be better to keep the initial proposal simpler and consider a followup in
>>> the Swift 5 timeframe to build on the initial proposal.
>>>
>>
>> For ==, the operator must already be "class final" or "static" regardless
>> of this proposal, and it can't be "overridden" as such in subclasses
>> because the arguments would be different (lhs and rhs would be the
>> subclass, not the superclass). So the compiler should be able to generate
>> the correct implementation for subclasses in all cases, right?
>>
>>
>> This won’t work because Equatable has a `Self` requirement so the `==`
>> defined by the initial conforming class would be called.  In order to
>> support non-final classes you would need to have that dispatch through
>> something like an `isEqual` method which *can* be 

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

[Xiaodi Wu via swift-evolution]

Hmm, with these complications, I regret suggesting that this could be
extended to classes so easily. Definitely some interesting solutions, but
my inclination as well would be to leave classes out entirely for the
moment and let it percolate for Swift 4.1+. After all, it's an additive
convenience.

Any thought as to including tuples though?
On Fri, May 5, 2017 at 13:51 Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

> On May 5, 2017, at 1:33 PM, Tony Allevato  wrote:
>
>
>
> On Fri, May 5, 2017 at 11:07 AM Matthew Johnson 
> wrote:
>
>> On May 5, 2017, at 10:45 AM, Tony Allevato via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Thanks for your feedback, everybody!
>>
>>
>> Thanks for continuing to drive this forward!
>>
>>
>> I've updated the gist
>>  to
>> reflect what seems to be a consensus here:
>>
>> * Derived conformances are now opt-in (this makes the recursive case
>> *much* cleaner, and the complexity involved in that section has been
>> completely removed)
>>
>>
>> Can the opt-in conformance be declared in an extension?  If so, can the
>> extension be in a different module than the original declaration?  If so,
>> do you intend any restrictions, such as requiring all members of the type
>> declared in a different module to be public?  My initial thought is that
>> this should be possible as long as all members are visible.
>>
>
> Declaring the conformance in an extension in the same module should
> definitely be allowed; I believe this would currently be the only way to
> support conditional conformances (such as the `Optional: Hashable where
> Wrapped: Hashable` example in the updated draft), without requiring deeper
> syntactic changes.
>
> I'm less sure about conformances being added in other modules, but I'm
> inclined to agree with your assessment. I could see two ways of
> interpreting it:
>
> * E/H can only be derived in an extension in an external module if all the
> members are accessible (and the other conditions are met).
> * E/H can be derived in an extension in an external module using only the
> subset of accessible members (if the other conditions are met).
>
> These are subtly different. The argument for the first would be "if you
> want to add E/H to a type in a different module, you must *consciously*
> decide which members you want to use in those computations". The argument
> for the second would be "you can already make a type in a different module
> conform to E/H and you'd be restricted to the accessible members there, so
> let's make that path easier for users too."
>
> The first case is probably the safer choice. I'm not sure about the
> implementation difficulty of each.
>
>
>> * Classes are supported now as well
>>
>> Please take a look at the updated version and let me know if there are
>> any concerns! If folks like it, I'll prepare a pull request.
>>
>>
>> Will the synthesis for classes dispatch through a non-final method which
>> is expected to be overridden by subclasses?  You don’t explicitly state
>> this but it seems implied.  If so, what if  the subclass requires a custom
>> implementation?  This would require the signature of the non-final method
>> to be part of the synthesis contract.
>>
>
>> Supporting non-final classes introduces enough complexity (especially
>> when multiple modules are involved).  I would hate to see it get
>> sidetracked in discussions regarding non-final classes and miss the Swift 4
>> window because of that.  Given the limited time left for Swift 4 it might
>> be better to keep the initial proposal simpler and consider a followup in
>> the Swift 5 timeframe to build on the initial proposal.
>>
>
> For ==, the operator must already be "class final" or "static" regardless
> of this proposal, and it can't be "overridden" as such in subclasses
> because the arguments would be different (lhs and rhs would be the
> subclass, not the superclass). So the compiler should be able to generate
> the correct implementation for subclasses in all cases, right?
>
>
> This won’t work because Equatable has a `Self` requirement so the `==`
> defined by the initial conforming class would be called.  In order to
> support non-final classes you would need to have that dispatch through
> something like an `isEqual` method which *can* be overridden.
>
>
> For hashValue, I think the possibilities are:
>
> * Sub is a subclass of Super. Super conforms to Hashable and implements
> non-final hashValue. The compiler can derive it for Sub and call
> super.hashValue in its implementation.
>
>
> Yes, this makes sense.  The primary difficulty with Hashable is that it
> refines Equatable.  Refining a non-final implementation of `hashValue` is
> relatively straightforward.
>
> * Sub is a subclass of Super. Super conforms to Hashable and implements a
> final hashValue. The compiler cannot derive one for Super and 

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

[Matthew Johnson via swift-evolution]

> On May 5, 2017, at 2:16 PM, Tony Allevato  wrote:
> 
> On Fri, May 5, 2017 at 11:51 AM Matthew Johnson  > wrote:
>> On May 5, 2017, at 1:33 PM, Tony Allevato > > wrote:
>> 
>> 
>> 
>> On Fri, May 5, 2017 at 11:07 AM Matthew Johnson > > wrote:
>>> On May 5, 2017, at 10:45 AM, Tony Allevato via swift-evolution 
>>> > wrote:
>>> 
>>> Thanks for your feedback, everybody!
>> 
>> Thanks for continuing to drive this forward!
>> 
>>> 
>>> I've updated the gist 
>>>  to 
>>> reflect what seems to be a consensus here:
>>> 
>>> * Derived conformances are now opt-in (this makes the recursive case *much* 
>>> cleaner, and the complexity involved in that section has been completely 
>>> removed)
>> 
>> Can the opt-in conformance be declared in an extension?  If so, can the 
>> extension be in a different module than the original declaration?  If so, do 
>> you intend any restrictions, such as requiring all members of the type 
>> declared in a different module to be public?  My initial thought is that 
>> this should be possible as long as all members are visible.
>> 
>> Declaring the conformance in an extension in the same module should 
>> definitely be allowed; I believe this would currently be the only way to 
>> support conditional conformances (such as the `Optional: Hashable where 
>> Wrapped: Hashable` example in the updated draft), without requiring deeper 
>> syntactic changes.
>> 
>> I'm less sure about conformances being added in other modules, but I'm 
>> inclined to agree with your assessment. I could see two ways of interpreting 
>> it:
>> 
>> * E/H can only be derived in an extension in an external module if all the 
>> members are accessible (and the other conditions are met).
>> * E/H can be derived in an extension in an external module using only the 
>> subset of accessible members (if the other conditions are met).
>> 
>> These are subtly different. The argument for the first would be "if you want 
>> to add E/H to a type in a different module, you must *consciously* decide 
>> which members you want to use in those computations". The argument for the 
>> second would be "you can already make a type in a different module conform 
>> to E/H and you'd be restricted to the accessible members there, so let's 
>> make that path easier for users too."
>> 
>> The first case is probably the safer choice. I'm not sure about the 
>> implementation difficulty of each.
>> 
>> 
>>> * Classes are supported now as well
>>> 
>>> Please take a look at the updated version and let me know if there are any 
>>> concerns! If folks like it, I'll prepare a pull request.
>> 
>> Will the synthesis for classes dispatch through a non-final method which is 
>> expected to be overridden by subclasses?  You don’t explicitly state this 
>> but it seems implied.  If so, what if  the subclass requires a custom 
>> implementation?  This would require the signature of the non-final method to 
>> be part of the synthesis contract.
>> 
>> Supporting non-final classes introduces enough complexity (especially when 
>> multiple modules are involved).  I would hate to see it get sidetracked in 
>> discussions regarding non-final classes and miss the Swift 4 window because 
>> of that.  Given the limited time left for Swift 4 it might be better to keep 
>> the initial proposal simpler and consider a followup in the Swift 5 
>> timeframe to build on the initial proposal.
>> 
>> For ==, the operator must already be "class final" or "static" regardless of 
>> this proposal, and it can't be "overridden" as such in subclasses because 
>> the arguments would be different (lhs and rhs would be the subclass, not the 
>> superclass). So the compiler should be able to generate the correct 
>> implementation for subclasses in all cases, right?
> 
> This won’t work because Equatable has a `Self` requirement so the `==` 
> defined by the initial conforming class would be called.  In order to support 
> non-final classes you would need to have that dispatch through something like 
> an `isEqual` method which *can* be overridden.
> 
> Ah crap, you're right. I was basing my experimentation on this example:
> 
> class Base: Equatable {
>   let x: Int
>   init(x: Int) { self.x = x }
>   static func == (lhs: Base, rhs: Base) -> Bool { return lhs.x == rhs.x }
> }
> 
> class Sub: Base {
>   let y: Int
>   init(x: Int, y: Int) { self.y = y; super.init(x: x) }
> 
>   static func == (lhs: Sub, rhs: Sub) -> Bool {
> guard lhs as Base == rhs as Base else {
>   return false
> }
> return lhs.y == rhs.y
>   }
> }
> 
> let s1 = Sub(x: 1, y: 2)
> let s2 = Sub(x: 1, y: 3)
> let s3 = Sub(x: 1, y: 2)
> 
> func usesBase(_ lhs: Base, _ 

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

[Tony Allevato via swift-evolution]

On Fri, May 5, 2017 at 11:51 AM Matthew Johnson 
wrote:

> On May 5, 2017, at 1:33 PM, Tony Allevato  wrote:
>
>
>
> On Fri, May 5, 2017 at 11:07 AM Matthew Johnson 
> wrote:
>
>> On May 5, 2017, at 10:45 AM, Tony Allevato via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Thanks for your feedback, everybody!
>>
>>
>> Thanks for continuing to drive this forward!
>>
>>
>> I've updated the gist
>>  to
>> reflect what seems to be a consensus here:
>>
>> * Derived conformances are now opt-in (this makes the recursive case
>> *much* cleaner, and the complexity involved in that section has been
>> completely removed)
>>
>>
>> Can the opt-in conformance be declared in an extension?  If so, can the
>> extension be in a different module than the original declaration?  If so,
>> do you intend any restrictions, such as requiring all members of the type
>> declared in a different module to be public?  My initial thought is that
>> this should be possible as long as all members are visible.
>>
>
> Declaring the conformance in an extension in the same module should
> definitely be allowed; I believe this would currently be the only way to
> support conditional conformances (such as the `Optional: Hashable where
> Wrapped: Hashable` example in the updated draft), without requiring deeper
> syntactic changes.
>
> I'm less sure about conformances being added in other modules, but I'm
> inclined to agree with your assessment. I could see two ways of
> interpreting it:
>
> * E/H can only be derived in an extension in an external module if all the
> members are accessible (and the other conditions are met).
> * E/H can be derived in an extension in an external module using only the
> subset of accessible members (if the other conditions are met).
>
> These are subtly different. The argument for the first would be "if you
> want to add E/H to a type in a different module, you must *consciously*
> decide which members you want to use in those computations". The argument
> for the second would be "you can already make a type in a different module
> conform to E/H and you'd be restricted to the accessible members there, so
> let's make that path easier for users too."
>
> The first case is probably the safer choice. I'm not sure about the
> implementation difficulty of each.
>
>
>> * Classes are supported now as well
>>
>> Please take a look at the updated version and let me know if there are
>> any concerns! If folks like it, I'll prepare a pull request.
>>
>>
>> Will the synthesis for classes dispatch through a non-final method which
>> is expected to be overridden by subclasses?  You don’t explicitly state
>> this but it seems implied.  If so, what if  the subclass requires a custom
>> implementation?  This would require the signature of the non-final method
>> to be part of the synthesis contract.
>>
>
>> Supporting non-final classes introduces enough complexity (especially
>> when multiple modules are involved).  I would hate to see it get
>> sidetracked in discussions regarding non-final classes and miss the Swift 4
>> window because of that.  Given the limited time left for Swift 4 it might
>> be better to keep the initial proposal simpler and consider a followup in
>> the Swift 5 timeframe to build on the initial proposal.
>>
>
> For ==, the operator must already be "class final" or "static" regardless
> of this proposal, and it can't be "overridden" as such in subclasses
> because the arguments would be different (lhs and rhs would be the
> subclass, not the superclass). So the compiler should be able to generate
> the correct implementation for subclasses in all cases, right?
>
>
> This won’t work because Equatable has a `Self` requirement so the `==`
> defined by the initial conforming class would be called.  In order to
> support non-final classes you would need to have that dispatch through
> something like an `isEqual` method which *can* be overridden.
>

Ah crap, you're right. I was basing my experimentation on this example:

class Base: Equatable {
  let x: Int
  init(x: Int) { self.x = x }
  static func == (lhs: Base, rhs: Base) -> Bool { return lhs.x == rhs.x }
}

class Sub: Base {
  let y: Int
  init(x: Int, y: Int) { self.y = y; super.init(x: x) }

  static func == (lhs: Sub, rhs: Sub) -> Bool {
guard lhs as Base == rhs as Base else {
  return false
}
return lhs.y == rhs.y
  }
}

let s1 = Sub(x: 1, y: 2)
let s2 = Sub(x: 1, y: 3)
let s3 = Sub(x: 1, y: 2)

func usesBase(_ lhs: Base, _ rhs: Base) -> Bool { return lhs == rhs }
func usesSub(_ lhs: Sub, _ rhs: Sub) -> Bool { return lhs == rhs }

print(usesSub(s1, s2)) // false (expected)
print(usesSub(s1, s3)) // true

print(usesBase(s1, s2)) // true (problematic)
print(usesBase(s1, s3)) // true


In that case the problematic behavior is "expected", but when you make it
generic, you're right that 

Re: [swift-evolution] Pitch: Omit deprecation warnings for same-file references

[Tony Allevato via swift-evolution]

On Fri, May 5, 2017 at 11:37 AM BJ Homer  wrote:

> I’ve run into this problem as well, when dealing with legacy file formats
> (similar to the example in the proposal), and I agree it would be nice to
> be able to address it. We’ve got a few “permanent” warnings in our code
> base right now due to this. I’m not sure whether the deprecation should be
> disabled for the entire file, though; perhaps it should be disabled just
> within the type itself? I don’t know how that would contribute to the
> complexity of the implementation, but it seems like we would still want to
> warn about deprecated accesses between two types declared in the same file.
>

I initially picked "same file" because (1) it appears to be dead simple to
implement and (2) the idea that if someone is marking a definition as
private in a file, they can easily go through the same file and resolve any
uses of that declaration if they no longer want them. But it's possible
that there are helper types that just happen to be in the same file where
you'd like to be warned about using those "privately allowed APIs", so
you're right that same-file suppression would make those harder to detect.

Given that, I'd be open to either of these possibilities and I'd love to
hear what others think:

* Give deprecation-suppression "fileprivate" semantics
* Give deprecation-suppression "private" semantics (suppressed in the same
type and in extensions of that type within the same file)




> -BJ Homer
>
> On May 5, 2017, at 12:12 PM, Tony Allevato via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hey Swift Evolvers,
>
> I'd like to propose a change that would suppress deprecation warnings when
> the reference to the deprecated declaration is in the same file as that
> declaration.
>
> This personally affects one of my projects (Swift protocol buffers)
> because .proto files allow declarations to be declared as deprecated, and
> we'd like to surface that by deprecating the equivalent declaration in the
> Swift code that we generate. We can't do this without generating noisy
> build logs, because we still need to reference the deprecated declarations
> to encode/decode the messages correctly; and the workarounds have
> significant performance penalties as described in the draft.
>
> I'd love some feedback from folks to know whether this—or something like
> it—is something that seems desirable/undesirable for the language. I've
> tinkered with an implementation in a branch
> 
> and it's fairly straightforward.
>
> Gist link:
> https://gist.github.com/allevato/76f098a761147f3be5017d10a6f4ecbb
>
>
> Omit deprecation warnings for same-file references
>
>- Proposal: SE-
>
> 
>- Author(s): Tony Allevato 
>- Status: Awaiting review
>
> 
>- Review manager: TBD
>
>
> 
> Introduction
>
> Public API developers can use the @available attribute in Swift to mark
> APIs as deprecated, which will emit warnings when a user references that
> API to notify them that that particular API is no longer preferred or may
> disappear in the future.
>
> These warnings are emitted for *any* reference to a deprecated entity,
> including those in the same file. In some cases, however, it may be
> necessary and correct to continue referring to the deprecated entity
> privately while discouraging its external use. In these scenarios, the
> warnings are superfluous and generate noise in the build logs. We propose
> eliminating these warnings for references made in the same file.
>
> Swift-evolution thread: TBD
> 
>
> 
> Motivation
>
> As APIs evolve, declarations may become deprecated but still need to be
> referenced privately in order to function correctly. For example, consider
> an object that is serialized/parsed between a client and server. The first
> iteration of such a type might look like this (the examples use a strawman
> API to avoid tying the discussion too closely with the new coding APIs,
> which is not the focus):
>
> public class Person {
>   public var name: String
>   public var phoneNumber: String?
>
>   public init(name: String, phoneNumber: String? = nil) {
> self.name = name
> self.phoneNumber = phoneNumber
>   }
>
>   public convenience init?(from reader: Reader) {
> guard let name = reader.readString(withKey: "name") else {
>   return nil
> }
> let phoneNumber = reader.readString(withKey: "phoneNumber")
> self.init(name: name, phoneNumber: phoneNumber)
>   }
>
>   public func write(to writer: Writer) {
>   

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

[Matthew Johnson via swift-evolution]

> On May 5, 2017, at 1:33 PM, Tony Allevato  wrote:
> 
> 
> 
> On Fri, May 5, 2017 at 11:07 AM Matthew Johnson  > wrote:
>> On May 5, 2017, at 10:45 AM, Tony Allevato via swift-evolution 
>> > wrote:
>> 
>> Thanks for your feedback, everybody!
> 
> Thanks for continuing to drive this forward!
> 
>> 
>> I've updated the gist 
>>  to 
>> reflect what seems to be a consensus here:
>> 
>> * Derived conformances are now opt-in (this makes the recursive case *much* 
>> cleaner, and the complexity involved in that section has been completely 
>> removed)
> 
> Can the opt-in conformance be declared in an extension?  If so, can the 
> extension be in a different module than the original declaration?  If so, do 
> you intend any restrictions, such as requiring all members of the type 
> declared in a different module to be public?  My initial thought is that this 
> should be possible as long as all members are visible.
> 
> Declaring the conformance in an extension in the same module should 
> definitely be allowed; I believe this would currently be the only way to 
> support conditional conformances (such as the `Optional: Hashable where 
> Wrapped: Hashable` example in the updated draft), without requiring deeper 
> syntactic changes.
> 
> I'm less sure about conformances being added in other modules, but I'm 
> inclined to agree with your assessment. I could see two ways of interpreting 
> it:
> 
> * E/H can only be derived in an extension in an external module if all the 
> members are accessible (and the other conditions are met).
> * E/H can be derived in an extension in an external module using only the 
> subset of accessible members (if the other conditions are met).
> 
> These are subtly different. The argument for the first would be "if you want 
> to add E/H to a type in a different module, you must *consciously* decide 
> which members you want to use in those computations". The argument for the 
> second would be "you can already make a type in a different module conform to 
> E/H and you'd be restricted to the accessible members there, so let's make 
> that path easier for users too."
> 
> The first case is probably the safer choice. I'm not sure about the 
> implementation difficulty of each.
> 
> 
>> * Classes are supported now as well
>> 
>> Please take a look at the updated version and let me know if there are any 
>> concerns! If folks like it, I'll prepare a pull request.
> 
> Will the synthesis for classes dispatch through a non-final method which is 
> expected to be overridden by subclasses?  You don’t explicitly state this but 
> it seems implied.  If so, what if  the subclass requires a custom 
> implementation?  This would require the signature of the non-final method to 
> be part of the synthesis contract.
> 
> Supporting non-final classes introduces enough complexity (especially when 
> multiple modules are involved).  I would hate to see it get sidetracked in 
> discussions regarding non-final classes and miss the Swift 4 window because 
> of that.  Given the limited time left for Swift 4 it might be better to keep 
> the initial proposal simpler and consider a followup in the Swift 5 timeframe 
> to build on the initial proposal.
> 
> For ==, the operator must already be "class final" or "static" regardless of 
> this proposal, and it can't be "overridden" as such in subclasses because the 
> arguments would be different (lhs and rhs would be the subclass, not the 
> superclass). So the compiler should be able to generate the correct 
> implementation for subclasses in all cases, right?

This won’t work because Equatable has a `Self` requirement so the `==` defined 
by the initial conforming class would be called.  In order to support non-final 
classes you would need to have that dispatch through something like an 
`isEqual` method which *can* be overridden.

> 
> For hashValue, I think the possibilities are:
> 
> * Sub is a subclass of Super. Super conforms to Hashable and implements 
> non-final hashValue. The compiler can derive it for Sub and call 
> super.hashValue in its implementation.

Yes, this makes sense.  The primary difficulty with Hashable is that it refines 
Equatable.  Refining a non-final implementation of `hashValue` is relatively 
straightforward.

> * Sub is a subclass of Super. Super conforms to Hashable and implements a 
> final hashValue. The compiler cannot derive one for Super and would silently 
> not do so.

Do you mean “the compiler cannot derive one for Sub”?

> * Sub is a subclass of Super. Super does not conform to Hashable, but Sub 
> asks to derive it. This can either (1) not be allowed, telling the user that 
> they need to write it manually in this case, or (2) be allowed and use all 
> accessible members to compute the hashValue (including 

Re: [swift-evolution] Pitch: Omit deprecation warnings for same-file references

[BJ Homer via swift-evolution]

I’ve run into this problem as well, when dealing with legacy file formats 
(similar to the example in the proposal), and I agree it would be nice to be 
able to address it. We’ve got a few “permanent” warnings in our code base right 
now due to this. I’m not sure whether the deprecation should be disabled for 
the entire file, though; perhaps it should be disabled just within the type 
itself? I don’t know how that would contribute to the complexity of the 
implementation, but it seems like we would still want to warn about deprecated 
accesses between two types declared in the same file.

-BJ Homer

> On May 5, 2017, at 12:12 PM, Tony Allevato via swift-evolution 
>  wrote:
> 
> Hey Swift Evolvers,
> 
> I'd like to propose a change that would suppress deprecation warnings when 
> the reference to the deprecated declaration is in the same file as that 
> declaration.
> 
> This personally affects one of my projects (Swift protocol buffers) because 
> .proto files allow declarations to be declared as deprecated, and we'd like 
> to surface that by deprecating the equivalent declaration in the Swift code 
> that we generate. We can't do this without generating noisy build logs, 
> because we still need to reference the deprecated declarations to 
> encode/decode the messages correctly; and the workarounds have significant 
> performance penalties as described in the draft.
> 
> I'd love some feedback from folks to know whether this—or something like 
> it—is something that seems desirable/undesirable for the language. I've 
> tinkered with an implementation in a branch 
> 
>  and it's fairly straightforward.
> 
> Gist link: https://gist.github.com/allevato/76f098a761147f3be5017d10a6f4ecbb 
> 
> 
> 
> Omit deprecation warnings for same-file references
> 
> Proposal: SE- 
> 
> Author(s): Tony Allevato 
> Status: Awaiting review 
> 
> Review manager: TBD
>  
> Introduction
> 
> Public API developers can use the @available attribute in Swift to mark APIs 
> as deprecated, which will emit warnings when a user references that API to 
> notify them that that particular API is no longer preferred or may disappear 
> in the future.
> 
> These warnings are emitted for any reference to a deprecated entity, 
> including those in the same file. In some cases, however, it may be necessary 
> and correct to continue referring to the deprecated entity privately while 
> discouraging its external use. In these scenarios, the warnings are 
> superfluous and generate noise in the build logs. We propose eliminating 
> these warnings for references made in the same file.
> 
> Swift-evolution thread: TBD 
> 
>  
> Motivation
> 
> As APIs evolve, declarations may become deprecated but still need to be 
> referenced privately in order to function correctly. For example, consider an 
> object that is serialized/parsed between a client and server. The first 
> iteration of such a type might look like this (the examples use a strawman 
> API to avoid tying the discussion too closely with the new coding APIs, which 
> is not the focus):
> 
> public class Person {
>   public var name: String
>   public var phoneNumber: String?
> 
>   public init(name: String, phoneNumber: String? = nil) {
> self.name = name
> self.phoneNumber = phoneNumber
>   }
> 
>   public convenience init?(from reader: Reader) {
> guard let name = reader.readString(withKey: "name") else {
>   return nil
> }
> let phoneNumber = reader.readString(withKey: "phoneNumber")
> self.init(name: name, phoneNumber: phoneNumber)
>   }
> 
>   public func write(to writer: Writer) {
> writer.write(name, key: "name")
> if let phoneNumber = phoneNumber {
>   writer.write(phoneNumber, key: "phoneNumber")
> }
>   }
> }
> Later, we decide that we need to support storing multiple phone numbers for a 
> Person. To avoid breaking source compatibility, we deprecate the old property 
> and add a new one. We still wish the encoding/decoding process to preserve 
> the integrity of the old data, however—for example, a middleman process used 
> for logging should not modify the data stream, so the encoding/decoding 
> process should not be also migrating the data. Thus, we update the class to 
> the following:
> 
> public class Person {
>   public var name: String
>   @available(*, deprecated, message: "use 'phoneNumbers' instead")
>   public var phoneNumber: String?
>   public 

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

[Tony Allevato via swift-evolution]

On Fri, May 5, 2017 at 11:07 AM Matthew Johnson 
wrote:

> On May 5, 2017, at 10:45 AM, Tony Allevato via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Thanks for your feedback, everybody!
>
>
> Thanks for continuing to drive this forward!
>
>
> I've updated the gist
>  to
> reflect what seems to be a consensus here:
>
> * Derived conformances are now opt-in (this makes the recursive case
> *much* cleaner, and the complexity involved in that section has been
> completely removed)
>
>
> Can the opt-in conformance be declared in an extension?  If so, can the
> extension be in a different module than the original declaration?  If so,
> do you intend any restrictions, such as requiring all members of the type
> declared in a different module to be public?  My initial thought is that
> this should be possible as long as all members are visible.
>

Declaring the conformance in an extension in the same module should
definitely be allowed; I believe this would currently be the only way to
support conditional conformances (such as the `Optional: Hashable where
Wrapped: Hashable` example in the updated draft), without requiring deeper
syntactic changes.

I'm less sure about conformances being added in other modules, but I'm
inclined to agree with your assessment. I could see two ways of
interpreting it:

* E/H can only be derived in an extension in an external module if all the
members are accessible (and the other conditions are met).
* E/H can be derived in an extension in an external module using only the
subset of accessible members (if the other conditions are met).

These are subtly different. The argument for the first would be "if you
want to add E/H to a type in a different module, you must *consciously*
decide which members you want to use in those computations". The argument
for the second would be "you can already make a type in a different module
conform to E/H and you'd be restricted to the accessible members there, so
let's make that path easier for users too."

The first case is probably the safer choice. I'm not sure about the
implementation difficulty of each.


> * Classes are supported now as well
>
> Please take a look at the updated version and let me know if there are any
> concerns! If folks like it, I'll prepare a pull request.
>
>
> Will the synthesis for classes dispatch through a non-final method which
> is expected to be overridden by subclasses?  You don’t explicitly state
> this but it seems implied.  If so, what if  the subclass requires a custom
> implementation?  This would require the signature of the non-final method
> to be part of the synthesis contract.
>

> Supporting non-final classes introduces enough complexity (especially when
> multiple modules are involved).  I would hate to see it get sidetracked in
> discussions regarding non-final classes and miss the Swift 4 window because
> of that.  Given the limited time left for Swift 4 it might be better to
> keep the initial proposal simpler and consider a followup in the Swift 5
> timeframe to build on the initial proposal.
>

For ==, the operator must already be "class final" or "static" regardless
of this proposal, and it can't be "overridden" as such in subclasses
because the arguments would be different (lhs and rhs would be the
subclass, not the superclass). So the compiler should be able to generate
the correct implementation for subclasses in all cases, right?

For hashValue, I think the possibilities are:

* Sub is a subclass of Super. Super conforms to Hashable and implements
non-final hashValue. The compiler can derive it for Sub and call
super.hashValue in its implementation.
* Sub is a subclass of Super. Super conforms to Hashable and implements a
final hashValue. The compiler cannot derive one for Super and would
silently not do so.
* Sub is a subclass of Super. Super does not conform to Hashable, but Sub
asks to derive it. This can either (1) not be allowed, telling the user
that they need to write it manually in this case, or (2) be allowed and use
all accessible members to compute the hashValue (including those from the
superclass).

What do Encodable/Decodable do in these situations? It seems similar
solutions there would apply here.

But after writing this all out, I'm inclined to agree that I'd rather see
structs/enums make it into Swift 4 even if it meant pushing classes to
Swift 4+x.



>
>
>
> On Fri, May 5, 2017 at 8:16 AM Nevin Brackett-Rozinsky via swift-evolution
>  wrote:
>
>> On Fri, May 5, 2017 at 1:47 AM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> On Fri, May 5, 2017 at 12:41 AM, Brent Royal-Gordon <
>>> br...@architechies.com> wrote:
>>>
 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 

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

[Robert Widmann via swift-evolution]

~Robert Widmann

2017/05/05 14:07、John McCall  のメッセージ:

>> On May 4, 2017, at 10:52 PM, Robert Widmann via swift-evolution 
>>  wrote:
>> - Parse: Has to account for the inclusion of tuple shuffles whenever it 
>> parses patterns (see the switch-statement example in the proposal)
> 
> This example doesn't make any sense.  Tuple shuffles are not responsible for 
> the rule that you cannot match an unlabelled tuple with a labelled tuple 
> pattern.  I'm really not sure what you think this would do, anyway; it's not 
> like tuple pattern element labels are lexically available.
> 

Exactly. I've since removed this example.  My initial confusion was around the 
labeled matching being a thing at all. 

>> - 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.
> 
> The type-checker doesn't have to do this with argument-matching.  It might do 
> it anyway, but it doesn't have to.
> 
>> - 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.
> 
> Call argument emission needs to deal with something like this anyway.  But 
> yes, we could eliminate the redundant path for ordinary r-value tuple 
> emission.
> 
> I'm not saying any of this to kill this proposal, just to clarify that the 
> complexity costs aren't as high as you seem to be saying.
> 
> John.
> 
>> 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
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0175 Package Manager Revised Dependency Resolution

[T.J. Usiyan via swift-evolution]

* What is your evaluation of the proposal?
+1

* Is the problem being addressed significant enough to warrant a change to
the Swift Package Manager?
Yes, pinning was fairly confusing to reason about

* Does this proposal fit well with the feel and direction of Swift?
I think so.

* If you have used other languages, libraries, or package managers with a
similar feature, how do you feel that this proposal compares to those?
This fits in pretty well. It isn't a huge deviation.

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

On Fri, May 5, 2017 at 2:55 AM, Martin Waitz via swift-evolution <
swift-evolution@swift.org> wrote:

> > * What is your evaluation of the proposal?
>
> I’m in favour of this proposal.
> It solves the problems I have with the current behaviour of the swift
> package manager.
>
> > * Is the problem being addressed significant enough to warrant a change
> to the Swift Package Manager?
>
> yes.
> While the existing auto-pinning feature can be used to get reproducible
> dependency versions,
> it has some deficiencies which make it more complicated than required for
> the common cases without really solving the more exotic use cases.
> Package pinning vs. requiring a specific revision in Package.swift also
> felt like two overlapping features without a clear motivation for one
> versus the other.
>
> > * Does this proposal fit well with the feel and direction of Swift?
>
> yes.
> It focuses on doing one thing well without precluding other user use cases.
> The new behaviour defaults does the right thing(TM) for the common use
> cases and is easily explained.
> Especially now that we are already able to require specific versions
> within Package.swift, SE-0150+SE-0175 provide a nice set of orthogonal
> features.
>
> > * If you have used other languages, libraries, or package managers with
> a similar feature, how do you feel that this proposal compares to those?
>
> Never used a package manager with this kind of dependency resolution and
> always wanted to have one.
>
> > * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
> Took part in the discussions for SE-0145 and now read SE-0175.
>
> —
> Martin
> ___
> 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: Omit deprecation warnings for same-file references

[Tony Allevato via swift-evolution]

Hey Swift Evolvers,

I'd like to propose a change that would suppress deprecation warnings when
the reference to the deprecated declaration is in the same file as that
declaration.

This personally affects one of my projects (Swift protocol buffers) because
.proto files allow declarations to be declared as deprecated, and we'd like
to surface that by deprecating the equivalent declaration in the Swift code
that we generate. We can't do this without generating noisy build logs,
because we still need to reference the deprecated declarations to
encode/decode the messages correctly; and the workarounds have significant
performance penalties as described in the draft.

I'd love some feedback from folks to know whether this—or something like
it—is something that seems desirable/undesirable for the language. I've
tinkered with an implementation in a branch

and it's fairly straightforward.

Gist link: https://gist.github.com/allevato/76f098a761147f3be5017d10a6f4ecbb


Omit deprecation warnings for same-file references

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


Introduction

Public API developers can use the @available attribute in Swift to mark
APIs as deprecated, which will emit warnings when a user references that
API to notify them that that particular API is no longer preferred or may
disappear in the future.

These warnings are emitted for *any* reference to a deprecated entity,
including those in the same file. In some cases, however, it may be
necessary and correct to continue referring to the deprecated entity
privately while discouraging its external use. In these scenarios, the
warnings are superfluous and generate noise in the build logs. We propose
eliminating these warnings for references made in the same file.

Swift-evolution thread: TBD


Motivation

As APIs evolve, declarations may become deprecated but still need to be
referenced privately in order to function correctly. For example, consider
an object that is serialized/parsed between a client and server. The first
iteration of such a type might look like this (the examples use a strawman
API to avoid tying the discussion too closely with the new coding APIs,
which is not the focus):

public class Person {
  public var name: String
  public var phoneNumber: String?

  public init(name: String, phoneNumber: String? = nil) {
self.name = name
self.phoneNumber = phoneNumber
  }

  public convenience init?(from reader: Reader) {
guard let name = reader.readString(withKey: "name") else {
  return nil
}
let phoneNumber = reader.readString(withKey: "phoneNumber")
self.init(name: name, phoneNumber: phoneNumber)
  }

  public func write(to writer: Writer) {
writer.write(name, key: "name")
if let phoneNumber = phoneNumber {
  writer.write(phoneNumber, key: "phoneNumber")
}
  }
}

Later, we decide that we need to support storing multiple phone numbers for
a Person. To avoid breaking source compatibility, we deprecate the old
property and add a new one. We still wish the encoding/decoding process to
preserve the integrity of the old data, however—for example, a middleman
process used for logging should not modify the data stream, so the
encoding/decoding process should not be also migrating the data. Thus, we
update the class to the following:

public class Person {
  public var name: String
  @available(*, deprecated, message: "use 'phoneNumbers' instead")
  public var phoneNumber: String?
  public var phoneNumbers: [String]

  @available(*, deprecated, message: "use 'init(name:phoneNumbers:)' instead")
  public convenience init(name: String, phoneNumber: String?) {
self.phoneNumber = phoneNumber
self.init(name: name, phoneNumbers: [])
  }

  public init(name: String, phoneNumbers: [String] = []) {
self.name = name
self.phoneNumber = nil
self.phoneNumbers = phoneNumbers
  }

  public convenience init?(from reader: Reader) {
guard let name = reader.readString(withKey: "name") else {
  return nil
}
let phoneNumbers = reader.readStringArray(withKey: "phoneNumbers") ?? []
self.phoneNumber = reader.readString(withKey: "phoneNumber")
self.init(name: name, phoneNumbers: phoneNumbers)
  }

  public func write(to writer: Writer) {
writer.write(name, key: "name")
if let phoneNumber = phoneNumber {
  writer.write(phoneNumber, key: "phoneNumber")
}
if !phoneNumbers.isEmpty {
  writer.write(phoneNumbers, key: 

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

[Matthew Johnson via swift-evolution]

> On May 5, 2017, at 10:45 AM, Tony Allevato via swift-evolution 
>  wrote:
> 
> Thanks for your feedback, everybody!

Thanks for continuing to drive this forward!

> 
> I've updated the gist 
>  to 
> reflect what seems to be a consensus here:
> 
> * Derived conformances are now opt-in (this makes the recursive case *much* 
> cleaner, and the complexity involved in that section has been completely 
> removed)

Can the opt-in conformance be declared in an extension?  If so, can the 
extension be in a different module than the original declaration?  If so, do 
you intend any restrictions, such as requiring all members of the type declared 
in a different module to be public?  My initial thought is that this should be 
possible as long as all members are visible.

> * Classes are supported now as well
> 
> Please take a look at the updated version and let me know if there are any 
> concerns! If folks like it, I'll prepare a pull request.

Will the synthesis for classes dispatch through a non-final method which is 
expected to be overridden by subclasses?  You don’t explicitly state this but 
it seems implied.  If so, what if  the subclass requires a custom 
implementation?  This would require the signature of the non-final method to be 
part of the synthesis contract.

Supporting non-final classes introduces enough complexity (especially when 
multiple modules are involved).  I would hate to see it get sidetracked in 
discussions regarding non-final classes and miss the Swift 4 window because of 
that.  Given the limited time left for Swift 4 it might be better to keep the 
initial proposal simpler and consider a followup in the Swift 5 timeframe to 
build on the initial proposal.

> 
> 
> On Fri, May 5, 2017 at 8:16 AM Nevin Brackett-Rozinsky via swift-evolution 
> > wrote:
> On Fri, May 5, 2017 at 1:47 AM, Xiaodi Wu via swift-evolution 
> > wrote:
> On Fri, May 5, 2017 at 12:41 AM, Brent Royal-Gordon  > wrote:
> 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.
> 
> I work so rarely with classes that I'm embarrassed to have to ask this 
> question: can classes not satisfy Equatable with a `public class func ==`?
> 
> Currently:
> 
> class C: Equatable {
> class func == (lhs: C, rhs: C) -> Bool {
> return lhs === rhs
> }
> }
> 
> Yields an error, “Operator '==' declared in non-final class 'C' must be 
> 'final'”.
> 
> Nevin
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[John McCall via swift-evolution]

> On May 4, 2017, at 10:52 PM, Robert Widmann via swift-evolution 
>  wrote:
> - Parse: Has to account for the inclusion of tuple shuffles whenever it 
> parses patterns (see the switch-statement example in the proposal)

This example doesn't make any sense.  Tuple shuffles are not responsible for 
the rule that you cannot match an unlabelled tuple with a labelled tuple 
pattern.  I'm really not sure what you think this would do, anyway; it's not 
like tuple pattern element labels are lexically available.

> - 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.

The type-checker doesn't have to do this with argument-matching.  It might do 
it anyway, but it doesn't have to.

> - 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.

Call argument emission needs to deal with something like this anyway.  But yes, 
we could eliminate the redundant path for ordinary r-value tuple emission.

I'm not saying any of this to kill this proposal, just to clarify that the 
complexity costs aren't as high as you seem to be saying.

John.

> 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

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

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

[Anders Ha via swift-evolution]

I don’t think overshadowing types defined in another module is an issue at all, 
in which case `Int` and `Void` belong to the Swift module.

Regards,
Anders

> On 5 May 2017, at 11:34 PM, Vladimir.S via swift-evolution 
>  wrote:
> 
> On 05.05.2017 6:12, Jose Cheyo Jimenez via swift-evolution wrote:
>> 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.
> 
> Very interesting. Could some one clarify, why this is allowed? Isn't this is 
> a bug we want to fix? At least by requiring a tilda like `Int`
> And of course, you can't "overload" user defined type:
> struct S {}
> let S = 10 // Error: invalid redeclaration of 'S'
> 
>> 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 )
>>> 

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

[Jose Cheyo Jimenez via swift-evolution]

I filled a bug report. https://bugs.swift.org/browse/SR-4811 



> On May 5, 2017, at 9:38 AM, Jose Cheyo Jimenez  wrote:
> 
> 
>> On May 5, 2017, at 8:34 AM, Vladimir.S > > wrote:
>> 
>> On 05.05.2017 6:12, Jose Cheyo Jimenez via swift-evolution wrote:
>>> 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.
>> 
>> Very interesting. Could some one clarify, why this is allowed? Isn't this is 
>> a bug we want to fix? At least by requiring a tilda like `Int`
>> And of course, you can't "overload" user defined type:
>> struct S {}
>> let S = 10 // Error: invalid redeclaration of ’S'
> 
> What version of swift are you using? Could it be a regression?
> 
> Welcome to Apple Swift version 3.1 (swiftlang-802.0.51 clang-802.0.41). Type 
> :help for assistance.
>   1> struct S {}
>   2> let S = 10
> S: Int = 10
>   3> print(S)
> error: repl.swift:3:7: error: ambiguous use of 'S'
> print(S)
>   ^
> 
> 
> 
>> 
>>> 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 
 

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

[Jose Cheyo Jimenez via swift-evolution]

> On May 5, 2017, at 8:34 AM, Vladimir.S  wrote:
> 
> On 05.05.2017 6:12, Jose Cheyo Jimenez via swift-evolution wrote:
>> 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.
> 
> Very interesting. Could some one clarify, why this is allowed? Isn't this is 
> a bug we want to fix? At least by requiring a tilda like `Int`
> And of course, you can't "overload" user defined type:
> struct S {}
> let S = 10 // Error: invalid redeclaration of ’S'

What version of swift are you using? Could it be a regression?

Welcome to Apple Swift version 3.1 (swiftlang-802.0.51 clang-802.0.41). Type 
:help for assistance.
  1> struct S {}
  2> let S = 10
S: Int = 10
  3> print(S)
error: repl.swift:3:7: error: ambiguous use of 'S'
print(S)
  ^



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

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

[Tony Allevato via swift-evolution]

Thanks for your feedback, everybody!

I've updated the gist
 to
reflect what seems to be a consensus here:

* Derived conformances are now opt-in (this makes the recursive case *much*
cleaner, and the complexity involved in that section has been completely
removed)
* Classes are supported now as well

Please take a look at the updated version and let me know if there are any
concerns! If folks like it, I'll prepare a pull request.


On Fri, May 5, 2017 at 8:16 AM Nevin Brackett-Rozinsky via swift-evolution <
swift-evolution@swift.org> wrote:

> On Fri, May 5, 2017 at 1:47 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Fri, May 5, 2017 at 12:41 AM, Brent Royal-Gordon <
>> br...@architechies.com> wrote:
>>
>>> 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.
>>>
>>
>> I work so rarely with classes that I'm embarrassed to have to ask this
>> question: can classes not satisfy Equatable with a `public class func ==`?
>>
>
> Currently:
>
> class C: Equatable {
> class func == (lhs: C, rhs: C) -> Bool {
> return lhs === rhs
> }
> }
>
> Yields an error, “Operator '==' declared in non-final class 'C' must be
> 'final'”.
>
> Nevin
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Vladimir.S via swift-evolution]

On 05.05.2017 6:12, Jose Cheyo Jimenez via swift-evolution wrote:
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.


Very interesting. Could some one clarify, why this is allowed? Isn't this is a bug we 
want to fix? At least by requiring a tilda like `Int`

And of course, you can't "overload" user defined type:
struct S {}
let S = 10 // Error: invalid redeclaration of 'S'




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

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

[T.J. Usiyan via swift-evolution]

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

^^I would like for this not to be possible.

That is not at all what I expect or–even now that I see what is
happening–desire in any way.

TJ

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

> To solve the issues with the destructuring I’d suggest to make the labels
> fully optional, so extracting inner tuples wouldn’t be a pain in the ass as
> it is right now.
>
> let tuple = (value: 0, point: (x: 0, y: 0, z: 0))
>
> let (value, point: (x, y, z)) = tuple
>
> Alternatively one could remove labels completely and let the compiler
> provide a suggestion for name of each value of the tuple destructuring, or
> you could your own names, while inner path would have some function-like
> syntax instead of confusing labels.
>
> let (value, point(x, y, z)) = tuple
>
> The latter would mean that tuple destructuring would always remove the
> labels from rhs tuple.
>
> In the example from above we’d get a change from:
>
> (value: Int, point: (x: Int, y: Int, z:Int)) to (Int, (Int, Int, Int)).
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 5. Mai 2017 um 14:07:11, André Videla (andre.vid...@gmail.com) schrieb:
>
> It really strikes me as an inconsistency in the type system. The type
> system already enforces order in other labeled expression like function
> calls
>
> func takePair(x: Int, y: Int) { }
>
> takePair(y: 5, x: 5) // error
>
> func takePair(y: Int, x: Int) { }
>
> takePair(y: 5, x: 5) // ok, dispatches to the second function because
> it's the only one that type checks with labels
>
> or enums
>
> enum Pair {
>
> case point(x: Int, y: Int)
>
> }
>
> let p: Pair = .point(y: 3, x: 4) // error
>
> Even if those features are semantically different and have nothing to do
> with the deconstruction of tuples they still suggest that labeling order is
> important. And teaches the programmer to expect that the order of labels is
> enforced.
>
> If you assume that label order is important why would you expect this to
> typecheck?
>
> let (y: a, x: b) = (x: 1, y: 2)
>
> let pair: (y: Int, x: Int) = (x: 1, y: 2)
>
> 2017-05-05 13:29 GMT+02:00 Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org>:
>
>> I’m confused here. You’re referring to this example:
>>
>> let pair = (x: 3, y: 5)
>> let swapped: (y: Int, x: Int) = pair
>>
>> In this case you’re shuffling/swapping the labels of the type from:
>>
>> (x: Int, y: Int) to (y: Int, x: Int), which from my understanding of the
>> whole pitch should be an error. The tuple types may look similar, but
>> because the labels have a totally different order, I’d assume the types are
>> different even if they share the same labels and types.
>>
>>
>> --
>> Adrian Zubarev
>> Sent with Airmail
>>
>> Am 5. Mai 2017 um 13:12:31, David Hart (da...@hartbit.com) schrieb:
>>
>> But we’re not reordering labels, we’re assigning to a different variable
>> which has different variable names. And I think it should work because we
>> are not using the restructuring syntax.
>>
>> On 5 May 2017, at 12:11, Adrian Zubarev 
>> wrote:
>>
>> I would assume the error is correct, because if we ban reordering than
>> labeled tuple types will become incompatible if the labels are swapped,
>> remember the strict order or labels.
>>
>>
>>
>> --
>> Adrian Zubarev
>> Sent with Airmail
>>
>> Am 5. Mai 2017 um 12:08:59, David Hart via swift-evolution (
>> swift-evolution@swift.org) schrieb:
>>
>>
>>
>> On 5 May 2017, at 10:59, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> On Fri, May 5, 2017 at 03:11 André Videla  wrote:
>>
>>>
>>> Just to make sure:
>>>
>>> let pair = (x: 3, y: 5)
>>> Let swapped: (y: Int, x: Int) = pair
>>>
>>
>> Error.
>>
>>
>> Why error here? In this case. It's not a label but he type.
>>
>> Let (y: x1, x: y1) = pair
>>>
>>
>> Error.
>>
>> Let (x: x2, y: y2) = pair
>>>
>>
>> With the revised pitch that no longer prohibits all labels, x2 is 3 and
>> y2 is 5. In the original version, error.
>>
>> Let (x3, y3) = pair
>>>
>>
>> x3 is 3 and y3 is 5.
>>
>> After the change, What do (x_n, y_n) print and Which assignments are
>>> errors?
>>>
>>> Andre Videla
>>>
>>> On 5 May 2017, at 09:31, Xiaodi Wu via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev >> artist.com> wrote:
>>>
 I’m not arguing to remove all labels in Swift. Labels are great, this
 is a fact for sure. The point I was trying to make is that labels in tuples
 how either a meaning or not at all.

 // This is a shortcut for the tuple type `(x: Int, y: Int)`
 let foo = (x: 0, y: 0)

 // In this case the labels are only used for description,
 // they do not server any benefit here are most likely redundant
 

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

[Nevin Brackett-Rozinsky via swift-evolution]

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

> On Fri, May 5, 2017 at 12:41 AM, Brent Royal-Gordon <
> br...@architechies.com> wrote:
>
>> 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.
>>
>
> I work so rarely with classes that I'm embarrassed to have to ask this
> question: can classes not satisfy Equatable with a `public class func ==`?
>

Currently:

class C: Equatable {
class func == (lhs: C, rhs: C) -> Bool {
return lhs === rhs
}
}

Yields an error, “Operator '==' declared in non-final class 'C' must be
'final'”.

Nevin
___
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]

To solve the issues with the destructuring I’d suggest to make the labels fully 
optional, so extracting inner tuples wouldn’t be a pain in the ass as it is 
right now.

let tuple = (value: 0, point: (x: 0, y: 0, z: 0))

let (value, point: (x, y, z)) = tuple
Alternatively one could remove labels completely and let the compiler provide a 
suggestion for name of each value of the tuple destructuring, or you could your 
own names, while inner path would have some function-like syntax instead of 
confusing labels.

let (value, point(x, y, z)) = tuple
The latter would mean that tuple destructuring would always remove the labels 
from rhs tuple.

In the example from above we’d get a change from:

(value: Int, point: (x: Int, y: Int, z:Int)) to (Int, (Int, Int, Int)).



-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 14:07:11, André Videla (andre.vid...@gmail.com) schrieb:

It really strikes me as an inconsistency in the type system. The type system 
already enforces order in other labeled expression like function calls
func takePair(x: Int, y: Int) { }

takePair(y: 5, x: 5) // error

func takePair(y: Int, x: Int) { }

takePair(y: 5, x: 5) // ok, dispatches to the second function because it's the 
only one that type checks with labels

or enums

enum Pair {

    case point(x: Int, y: Int)

}

let p: Pair = .point(y: 3, x: 4) // error

Even if those features are semantically different and have nothing to do with 
the deconstruction of tuples they still suggest that labeling order is 
important. And teaches the programmer to expect that the order of labels is 
enforced.

If you assume that label order is important why would you expect this to 
typecheck?

let (y: a, x: b) = (x: 1, y: 2) 

let pair: (y: Int, x: Int) = (x: 1, y: 2)


2017-05-05 13:29 GMT+02:00 Adrian Zubarev via swift-evolution 
:
I’m confused here. You’re referring to this example:

let pair = (x: 3, y: 5)
let swapped: (y: Int, x: Int) = pair
In this case you’re shuffling/swapping the labels of the type from:

(x: Int, y: Int) to (y: Int, x: Int), which from my understanding of the whole 
pitch should be an error. The tuple types may look similar, but because the 
labels have a totally different order, I’d assume the types are different even 
if they share the same labels and types.



-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 13:12:31, David Hart (da...@hartbit.com) schrieb:

But we’re not reordering labels, we’re assigning to a different variable which 
has different variable names. And I think it should work because we are not 
using the restructuring syntax.

On 5 May 2017, at 12:11, Adrian Zubarev  wrote:

I would assume the error is correct, because if we ban reordering than labeled 
tuple types will become incompatible if the labels are swapped, remember the 
strict order or labels. 




-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 12:08:59, David Hart via swift-evolution 
(swift-evolution@swift.org) schrieb:



On 5 May 2017, at 10:59, Xiaodi Wu via swift-evolution 
 wrote:

On Fri, May 5, 2017 at 03:11 André Videla  wrote:

Just to make sure:

let pair = (x: 3, y: 5)
Let swapped: (y: Int, x: Int) = pair

Error.

Why error here? In this case. It's not a label but he type.

Let (y: x1, x: y1) = pair

Error.

Let (x: x2, y: y2) = pair

With the revised pitch that no longer prohibits all labels, x2 is 3 and y2 is 
5. In the original version, error.

Let (x3, y3) = pair

x3 is 3 and y3 is 5.

After the change, What do (x_n, y_n) print and Which assignments are errors?

Andre Videla 

On 5 May 2017, at 09:31, Xiaodi Wu via swift-evolution 
 wrote:

On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev 
 wrote:
I’m not arguing to remove all labels in Swift. Labels are great, this is a fact 
for sure. The point I was trying to make is that labels in tuples how either a 
meaning or not at all.

// This is a shortcut for the tuple type `(x: Int, y: Int)`
let foo = (x: 0, y: 0) 

// In this case the labels are only used for description, 
// they do not server any benefit here are most likely redundant
let (x: x, y: y) = foo 
Labels elsewhere are a different story and I do support the cosmetic addition 
Chris Lattner sketched out here: 
https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html

However this is about closures and not tuples, I don’t think this would anyhow 
affect the removal of labels in tuple destructuring.

Plus I don’t see this to create an inconsistent in Swift, because as I already 
said, labels in tuple destructuring are useless.

How come? I just illustrated their use. They help humans write correct code by 
allowing the compiler to check an assertion that the human knows which labels 
go with which positions in the tuple.
___

swift-evolution mailing list

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

[Adrian Zubarev via swift-evolution]

I don’t understand your question. Those two lines of code should be an error 
and it’s exactly what the current draft is trying to fix.

This behavior is truly inconsistent.



-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 14:07:11, André Videla (andre.vid...@gmail.com) schrieb:

If you assume that label order is important why would you expect this to 
typecheck?

let (y: a, x: b) = (x: 1, y: 2) 

let pair: (y: Int, x: Int) = (x: 1, y: 2)

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

I’m confused here. You’re referring to this example:

let pair = (x: 3, y: 5)
let swapped: (y: Int, x: Int) = pair
In this case you’re shuffling/swapping the labels of the type from:

(x: Int, y: Int) to (y: Int, x: Int), which from my understanding of the whole 
pitch should be an error. The tuple types may look similar, but because the 
labels have a totally different order, I’d assume the types are different even 
if they share the same labels and types.



-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 13:12:31, David Hart (da...@hartbit.com) schrieb:

But we’re not reordering labels, we’re assigning to a different variable which 
has different variable names. And I think it should work because we are not 
using the restructuring syntax.

On 5 May 2017, at 12:11, Adrian Zubarev  wrote:

I would assume the error is correct, because if we ban reordering than labeled 
tuple types will become incompatible if the labels are swapped, remember the 
strict order or labels. 




-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 12:08:59, David Hart via swift-evolution 
(swift-evolution@swift.org) schrieb:



On 5 May 2017, at 10:59, Xiaodi Wu via swift-evolution 
 wrote:

On Fri, May 5, 2017 at 03:11 André Videla  wrote:

Just to make sure:

let pair = (x: 3, y: 5)
Let swapped: (y: Int, x: Int) = pair

Error.

Why error here? In this case. It's not a label but he type.

Let (y: x1, x: y1) = pair

Error.

Let (x: x2, y: y2) = pair

With the revised pitch that no longer prohibits all labels, x2 is 3 and y2 is 
5. In the original version, error.

Let (x3, y3) = pair

x3 is 3 and y3 is 5.

After the change, What do (x_n, y_n) print and Which assignments are errors?

Andre Videla 

On 5 May 2017, at 09:31, Xiaodi Wu via swift-evolution 
 wrote:

On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev 
 wrote:
I’m not arguing to remove all labels in Swift. Labels are great, this is a fact 
for sure. The point I was trying to make is that labels in tuples how either a 
meaning or not at all.

// This is a shortcut for the tuple type `(x: Int, y: Int)`
let foo = (x: 0, y: 0)

// In this case the labels are only used for description,
// they do not server any benefit here are most likely redundant
let (x: x, y: y) = foo
Labels elsewhere are a different story and I do support the cosmetic addition 
Chris Lattner sketched out here: 
https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html

However this is about closures and not tuples, I don’t think this would anyhow 
affect the removal of labels in tuple destructuring.

Plus I don’t see this to create an inconsistent in Swift, because as I already 
said, labels in tuple destructuring are useless.

How come? I just illustrated their use. They help humans write correct code by 
allowing the compiler to check an assertion that the human knows which labels 
go with which positions in the tuple.
___

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

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

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

[David Hart via swift-evolution]

But we’re not reordering labels, we’re assigning to a different variable which 
has different variable names. And I think it should work because we are not 
using the restructuring syntax.

> On 5 May 2017, at 12:11, Adrian Zubarev  
> wrote:
> 
> I would assume the error is correct, because if we ban reordering than 
> labeled tuple types will become incompatible if the labels are swapped, 
> remember the strict order or labels. 
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 5. Mai 2017 um 12:08:59, David Hart via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> 
>> 
>> On 5 May 2017, at 10:59, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>>> On Fri, May 5, 2017 at 03:11 André Videla >> > wrote:
>>> 
>>> Just to make sure:
>>> 
>>> let pair = (x: 3, y: 5)
>>> Let swapped: (y: Int, x: Int) = pair
>>> 
>>> Error.
>> 
>> Why error here? In this case. It's not a label but he type.
>> 
>>> Let (y: x1, x: y1) = pair
>>> 
>>> Error.
>>> 
>>> Let (x: x2, y: y2) = pair
>>> 
>>> With the revised pitch that no longer prohibits all labels, x2 is 3 and y2 
>>> is 5. In the original version, error.
>>> 
>>> Let (x3, y3) = pair
>>> 
>>> x3 is 3 and y3 is 5.
>>> 
>>> After the change, What do (x_n, y_n) print and Which assignments are errors?
>>> 
>>> Andre Videla 
>>> 
>>> On 5 May 2017, at 09:31, Xiaodi Wu via swift-evolution 
>>> > wrote:
>>> 
 On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev 
 > 
 wrote:
 I’m not arguing to remove all labels in Swift. Labels are great, this is a 
 fact for sure. The point I was trying to make is that labels in tuples how 
 either a meaning or not at all.
 
 // This is a shortcut for the tuple type `(x: Int, y: Int)`
 let foo = (x: 0, y: 0)   
 
 // In this case the labels are only used for description,   
 // they do not server any benefit here are most likely redundant
 let (x: x, y: y) = foo   
 Labels elsewhere are a different story and I do support the cosmetic 
 addition Chris Lattner sketched out here: 
 https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html
  
 
 However this is about closures and not tuples, I don’t think this would 
 anyhow affect the removal of labels in tuple destructuring.
 
 Plus I don’t see this to create an inconsistent in Swift, because as I 
 already said, labels in tuple destructuring are useless.
 
 How come? I just illustrated their use. They help humans write correct 
 code by allowing the compiler to check an assertion that the human knows 
 which labels go with which positions in the tuple.
>>> 
 ___
>>> 
 
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 

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

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

[Adrian Zubarev via swift-evolution]

IMHO the following line of code contains a highly inconsistent syntax, because 
the rhs uses labels for some sort of assignment, where the lhs just marks a 
constant/variable after the colon.

let (x: x, y: y) = (x: 0, y: 0) // valid today


-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 12:42:11, Adrian Zubarev (adrian.zuba...@devandartist.com) 
schrieb:

Labels create more harm in tuple destructuring than they solve.

let point = (x: 0, y: 0)

let (myX, myY) = point // fine
let (x: my_X, y: my_Y) = point // fine

let tuple = (a: 0, innerTuple: point)

let (myA, myInnerTuple) = tuple

// The following destructuring can extract nested tuples as well
let (a: a, innerTuple: (x: x, y: y)) = tuple // fine

// Let's try the same without labels
let (my_A, (myNewX, myNewY)) = tuple
// error: cannot express tuple conversion '(a: Int, innerTuple: (x: Int, y: 
Int))' to '(Int, (Int, Int))'
// Wait what? It did worked above with `point`

// Let's try something else
let (a: _, innerTuple: (newX, newY)) = tuple
// '(a: Int, innerTuple: (x: Int, y: Int))' to '(a: Int, innerTuple: (Int, 
Int))'

// Yet another approach
let (a: _, innerTuple: inner) = tuple // fine
>From this I conclude that tuple destructuring creates a new tuple, which is 
>not my intention at all, at least not in terms of extracting data. The types 
>become incompatible with each other if not labeled properly and that’s why we 
>cannot omit unwanted labels and are forced to either type them all out to 
>extract nested data or none of them at all.



-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 09:32:02, Xiaodi Wu (xiaodi...@gmail.com) schrieb:

On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev 
 wrote:
I’m not arguing to remove all labels in Swift. Labels are great, this is a fact 
for sure. The point I was trying to make is that labels in tuples how either a 
meaning or not at all.

// This is a shortcut for the tuple type `(x: Int, y: Int)`
let foo = (x: 0, y: 0)

// In this case the labels are only used for description,
// they do not server any benefit here are most likely redundant
let (x: x, y: y) = foo
Labels elsewhere are a different story and I do support the cosmetic addition 
Chris Lattner sketched out here: 
https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html

However this is about closures and not tuples, I don’t think this would anyhow 
affect the removal of labels in tuple destructuring.

Plus I don’t see this to create an inconsistent in Swift, because as I already 
said, labels in tuple destructuring are useless.

How come? I just illustrated their use. They help humans write correct code by 
allowing the compiler to check an assertion that the human knows which labels 
go with which positions in the tuple.
___
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]

Labels create more harm in tuple destructuring than they solve.

let point = (x: 0, y: 0)

let (myX, myY) = point // fine
let (x: my_X, y: my_Y) = point // fine

let tuple = (a: 0, innerTuple: point)

let (myA, myInnerTuple) = tuple

// The following destructuring can extract nested tuples as well
let (a: a, innerTuple: (x: x, y: y)) = tuple // fine

// Let's try the same without labels
let (my_A, (myNewX, myNewY)) = tuple
// error: cannot express tuple conversion '(a: Int, innerTuple: (x: Int, y: 
Int))' to '(Int, (Int, Int))'
// Wait what? It did worked above with `point`

// Let's try something else
let (a: _, innerTuple: (newX, newY)) = tuple
// '(a: Int, innerTuple: (x: Int, y: Int))' to '(a: Int, innerTuple: (Int, 
Int))'

// Yet another approach
let (a: _, innerTuple: inner) = tuple // fine
>From this I conclude that tuple destructuring creates a new tuple, which is 
>not my intention at all, at least not in terms of extracting data. The types 
>become incompatible with each other if not labeled properly and that’s why we 
>cannot omit unwanted labels and are forced to either type them all out to 
>extract nested data or none of them at all.



-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 09:32:02, Xiaodi Wu (xiaodi...@gmail.com) schrieb:

On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev 
 wrote:
I’m not arguing to remove all labels in Swift. Labels are great, this is a fact 
for sure. The point I was trying to make is that labels in tuples how either a 
meaning or not at all.

// This is a shortcut for the tuple type `(x: Int, y: Int)`
let foo = (x: 0, y: 0)   

// In this case the labels are only used for description,   
// they do not server any benefit here are most likely redundant
let (x: x, y: y) = foo   
Labels elsewhere are a different story and I do support the cosmetic addition 
Chris Lattner sketched out here: 
https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html

However this is about closures and not tuples, I don’t think this would anyhow 
affect the removal of labels in tuple destructuring.

Plus I don’t see this to create an inconsistent in Swift, because as I already 
said, labels in tuple destructuring are useless.

How come? I just illustrated their use. They help humans write correct code by 
allowing the compiler to check an assertion that the human knows which labels 
go with which positions in the tuple.
___
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]

You’ve got your manual reordering wrong:

let a = (x: 1, y: 2)
var b: (y:Int, x:Int)

b = a // warning
b = (x: a.x, y: a.y) // explicit, manual reordering
It should be:

b = (y: a.y, x: a.x) // explicit, manual reordering


-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 11:48:50, Haravikk via swift-evolution 
(swift-evolution@swift.org) schrieb:

let a = (x: 1, y: 2)
var b: (y:Int, x:Int)

b = a // warning
b = (x: a.x, y: a.y) // explicit, manual reordering
___
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]

I would assume the error is correct, because if we ban reordering than labeled 
tuple types will become incompatible if the labels are swapped, remember the 
strict order or labels.



-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 12:08:59, David Hart via swift-evolution 
(swift-evolution@swift.org) schrieb:



On 5 May 2017, at 10:59, Xiaodi Wu via swift-evolution 
 wrote:

On Fri, May 5, 2017 at 03:11 André Videla  wrote:

Just to make sure:

let pair = (x: 3, y: 5)
Let swapped: (y: Int, x: Int) = pair

Error.

Why error here? In this case. It's not a label but he type.

Let (y: x1, x: y1) = pair

Error.

Let (x: x2, y: y2) = pair

With the revised pitch that no longer prohibits all labels, x2 is 3 and y2 is 
5. In the original version, error.

Let (x3, y3) = pair

x3 is 3 and y3 is 5.

After the change, What do (x_n, y_n) print and Which assignments are errors?

Andre Videla 

On 5 May 2017, at 09:31, Xiaodi Wu via swift-evolution 
 wrote:

On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev 
 wrote:
I’m not arguing to remove all labels in Swift. Labels are great, this is a fact 
for sure. The point I was trying to make is that labels in tuples how either a 
meaning or not at all.

// This is a shortcut for the tuple type `(x: Int, y: Int)`
let foo = (x: 0, y: 0)   

// In this case the labels are only used for description,   
// they do not server any benefit here are most likely redundant
let (x: x, y: y) = foo   
Labels elsewhere are a different story and I do support the cosmetic addition 
Chris Lattner sketched out here: 
https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html

However this is about closures and not tuples, I don’t think this would anyhow 
affect the removal of labels in tuple destructuring.

Plus I don’t see this to create an inconsistent in Swift, because as I already 
said, labels in tuple destructuring are useless.

How come? I just illustrated their use. They help humans write correct code by 
allowing the compiler to check an assertion that the human knows which labels 
go with which positions in the tuple.
___

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

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

[David Hart via swift-evolution]

> On 5 May 2017, at 10:59, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Fri, May 5, 2017 at 03:11 André Videla  wrote:
>> 
>> Just to make sure:
>> 
>> let pair = (x: 3, y: 5)
>> Let swapped: (y: Int, x: Int) = pair
> 
> Error.

Why error here? In this case. It's not a label but he type.

>> Let (y: x1, x: y1) = pair
> 
> Error.
> 
>> Let (x: x2, y: y2) = pair
> 
> With the revised pitch that no longer prohibits all labels, x2 is 3 and y2 is 
> 5. In the original version, error.
> 
>> Let (x3, y3) = pair
> 
> x3 is 3 and y3 is 5.
> 
>> After the change, What do (x_n, y_n) print and Which assignments are errors?
>> 
>> Andre Videla 
>> 
>>> On 5 May 2017, at 09:31, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
 On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev 
  wrote:
 I’m not arguing to remove all labels in Swift. Labels are great, this is a 
 fact for sure. The point I was trying to make is that labels in tuples how 
 either a meaning or not at all.
 
 // This is a shortcut for the tuple type `(x: Int, y: Int)`
 let foo = (x: 0, y: 0)  
 
 // In this case the labels are only used for description,  
 // they do not server any benefit here are most likely redundant
 let (x: x, y: y) = foo  
 Labels elsewhere are a different story and I do support the cosmetic 
 addition Chris Lattner sketched out here: 
 https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html
 
 However this is about closures and not tuples, I don’t think this would 
 anyhow affect the removal of labels in tuple destructuring.
 
 Plus I don’t see this to create an inconsistent in Swift, because as I 
 already said, labels in tuple destructuring are useless.
 
>>> How come? I just illustrated their use. They help humans write correct code 
>>> by allowing the compiler to check an assertion that the human knows which 
>>> labels go with which positions in the tuple.
>> 
>>> ___
>> 
>>> 
>>> 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] [Proposal][Discussion] Deprecate Tuple Shuffles

[André Videla via swift-evolution]

Then +1 for the revised pitch. I strongly believe this is a strict improvement 
over the current situation.

 (y: Int, x: Int) = (x: 1, y:2) really looks like a type error

Andre Videla 

> On 5 May 2017, at 10:59, Xiaodi Wu  wrote:
> 
>> On Fri, May 5, 2017 at 03:11 André Videla  wrote:
>> 
>> Just to make sure:
>> 
>> let pair = (x: 3, y: 5)
>> Let swapped: (y: Int, x: Int) = pair
> 
> Error.
> 
>> Let (y: x1, x: y1) = pair
> 
> Error.
> 
>> Let (x: x2, y: y2) = pair
> 
> With the revised pitch that no longer prohibits all labels, x2 is 3 and y2 is 
> 5. In the original version, error.
> 
>> Let (x3, y3) = pair
> 
> x3 is 3 and y3 is 5.
> 
>> After the change, What do (x_n, y_n) print and Which assignments are errors?
>> 
>> Andre Videla 
>> 
>>> On 5 May 2017, at 09:31, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
 On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev 
  wrote:
 I’m not arguing to remove all labels in Swift. Labels are great, this is a 
 fact for sure. The point I was trying to make is that labels in tuples how 
 either a meaning or not at all.
 
 // This is a shortcut for the tuple type `(x: Int, y: Int)`
 let foo = (x: 0, y: 0)  
 
 // In this case the labels are only used for description,  
 // they do not server any benefit here are most likely redundant
 let (x: x, y: y) = foo  
 Labels elsewhere are a different story and I do support the cosmetic 
 addition Chris Lattner sketched out here: 
 https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html
 
 However this is about closures and not tuples, I don’t think this would 
 anyhow affect the removal of labels in tuple destructuring.
 
 Plus I don’t see this to create an inconsistent in Swift, because as I 
 already said, labels in tuple destructuring are useless.
 
>>> How come? I just illustrated their use. They help humans write correct code 
>>> by allowing the compiler to check an assertion that the human knows which 
>>> labels go with which positions in the tuple.
>> 
>>> ___
>> 
>>> 
>>> 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

[Haravikk via swift-evolution]

I have to admit I've become confused by what exactly this proposal is trying to 
fix as there's a lot of talk about removing labels entirely or something? I'm 
very wary about that.

> On 5 May 2017, at 03:14, Robert Widmann via swift-evolution 
>  wrote:
> 
> let a = (x: 1, y: 2)
> var b: (y: Int, x: Int)
> b = a
However, for this specific case above I do agree that a warning should be 
added, as the implicit behaviour here could all too easily be a mistake. I 
would prefer instead the developers either manually reorder the values, and 
perhaps that an operator be added to explicitly perform automatic reordering. 
Perhaps a tilde? Like so:

let a = (x: 1, y: 2)
var b: (y:Int, x:Int)

b = a // warning
b = (x: a.x, y: a.y) // explicit, manual reordering
b = ~a // implicit, automatic reordering by label matching (still 
warns/errors on type mismatch)

As for any other changes however, I think these should be addressed in their 
own proposals as I think discussion is getting too broad and confusing IMO.___
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 03:11 André Videla  wrote:

>
> Just to make sure:
>
> let pair = (x: 3, y: 5)
> Let swapped: (y: Int, x: Int) = pair
>

Error.

Let (y: x1, x: y1) = pair
>

Error.

Let (x: x2, y: y2) = pair
>

With the revised pitch that no longer prohibits all labels, x2 is 3 and y2
is 5. In the original version, error.

Let (x3, y3) = pair
>

x3 is 3 and y3 is 5.

After the change, What do (x_n, y_n) print and Which assignments are errors?
>
> Andre Videla
>
> On 5 May 2017, at 09:31, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev <
> adrian.zuba...@devandartist.com> wrote:
>
>> I’m not arguing to remove all labels in Swift. Labels are great, this is
>> a fact for sure. The point I was trying to make is that labels in tuples
>> how either a meaning or not at all.
>>
>> // This is a shortcut for the tuple type `(x: Int, y: Int)`
>> let foo = (x: 0, y: 0)
>>
>> // In this case the labels are only used for description,
>> // they do not server any benefit here are most likely redundant
>> let (x: x, y: y) = foo
>>
>> Labels elsewhere are a different story and I do support the cosmetic
>> addition Chris Lattner sketched out here:
>> https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html
>>
>> However this is about closures and not tuples, I don’t think this would
>> anyhow affect the removal of labels in tuple destructuring.
>>
>> Plus I don’t see this to create an inconsistent in Swift, because as I
>> already said, labels in tuple destructuring are useless.
>>
> How come? I just illustrated their use. They help humans write correct
> code by allowing the compiler to check an assertion that the human knows
> which labels go with which positions in the tuple.
>
> ___
>
>
> 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

[Rien via swift-evolution]

> On 05 May 2017, at 09:59, Xiaodi Wu  wrote:
> 
> On Fri, May 5, 2017 at 2:56 AM, Rien  wrote:
> 
> > On 05 May 2017, at 09:31, Xiaodi Wu via swift-evolution 
> >  wrote:
> >
> > On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev 
> >  wrote:
> > I’m not arguing to remove all labels in Swift. Labels are great, this is a 
> > fact for sure. The point I was trying to make is that labels in tuples how 
> > either a meaning or not at all.
> >
> > // This is a shortcut for the tuple type `(x: Int, y: Int)`
> > let foo = (x: 0, y: 0)
> >
> > // In this case the labels are only used for description,
> > // they do not server any benefit here are most likely redundant
> > let (x: x, y: y) = foo
> >
> > Labels elsewhere are a different story and I do support the cosmetic 
> > addition Chris Lattner sketched out here: 
> > https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html
> >
> > However this is about closures and not tuples, I don’t think this would 
> > anyhow affect the removal of labels in tuple destructuring.
> >
> > Plus I don’t see this to create an inconsistent in Swift, because as I 
> > already said, labels in tuple destructuring are useless.
> >
> > How come? I just illustrated their use. They help humans write correct code 
> > by allowing the compiler to check an assertion that the human knows which 
> > labels go with which positions in the tuple.
> 
> True, but the ability to define your own labels (instead of the API developer 
> defining them for you) can make your code more readable. and hence 
> maintainable.
> 
> I'm not sure I understand what you're suggesting here. Can you clarify?

In trying to explain, I discovered an error in my thinking… so please disregard.

Rien.

(Btw: Thanks for asking!)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[André Videla via swift-evolution]

Just to make sure:

let pair = (x: 3, y: 5)
Let swapped: (y: Int, x: Int) = pair
Let (y: x1, x: y1) = pair
Let (x: x2, y: y2) = pair
Let (x3, y3) = pair

After the change, What do (x_n, y_n) print and Which assignments are errors?

Andre Videla 

>> On 5 May 2017, at 09:31, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev 
>>  wrote:
>> I’m not arguing to remove all labels in Swift. Labels are great, this is a 
>> fact for sure. The point I was trying to make is that labels in tuples how 
>> either a meaning or not at all.
>> 
>> // This is a shortcut for the tuple type `(x: Int, y: Int)`
>> let foo = (x: 0, y: 0)  
>> 
>> // In this case the labels are only used for description,  
>> // they do not server any benefit here are most likely redundant
>> let (x: x, y: y) = foo  
>> Labels elsewhere are a different story and I do support the cosmetic 
>> addition Chris Lattner sketched out here: 
>> https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html
>> 
>> However this is about closures and not tuples, I don’t think this would 
>> anyhow affect the removal of labels in tuple destructuring.
>> 
>> Plus I don’t see this to create an inconsistent in Swift, because as I 
>> already said, labels in tuple destructuring are useless.
>> 
> How come? I just illustrated their use. They help humans write correct code 
> by allowing the compiler to check an assertion that the human knows which 
> labels go with which positions in the tuple.
> ___
> 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]

On Fri, May 5, 2017 at 2:56 AM, Rien  wrote:

>
> > On 05 May 2017, at 09:31, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev <
> adrian.zuba...@devandartist.com> wrote:
> > I’m not arguing to remove all labels in Swift. Labels are great, this is
> a fact for sure. The point I was trying to make is that labels in tuples
> how either a meaning or not at all.
> >
> > // This is a shortcut for the tuple type `(x: Int, y: Int)`
> > let foo = (x: 0, y: 0)
> >
> > // In this case the labels are only used for description,
> > // they do not server any benefit here are most likely redundant
> > let (x: x, y: y) = foo
> >
> > Labels elsewhere are a different story and I do support the cosmetic
> addition Chris Lattner sketched out here: https://lists.swift.org/
> pipermail/swift-evolution-announce/2016-July/000233.html
> >
> > However this is about closures and not tuples, I don’t think this would
> anyhow affect the removal of labels in tuple destructuring.
> >
> > Plus I don’t see this to create an inconsistent in Swift, because as I
> already said, labels in tuple destructuring are useless.
> >
> > How come? I just illustrated their use. They help humans write correct
> code by allowing the compiler to check an assertion that the human knows
> which labels go with which positions in the tuple.
>
> True, but the ability to define your own labels (instead of the API
> developer defining them for you) can make your code more readable. and
> hence maintainable.
>

I'm not sure I understand what you're suggesting here. Can you clarify?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rien via swift-evolution]

> On 05 May 2017, at 09:31, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev 
>  wrote:
> I’m not arguing to remove all labels in Swift. Labels are great, this is a 
> fact for sure. The point I was trying to make is that labels in tuples how 
> either a meaning or not at all.
> 
> // This is a shortcut for the tuple type `(x: Int, y: Int)`
> let foo = (x: 0, y: 0)  
> 
> // In this case the labels are only used for description,  
> // they do not server any benefit here are most likely redundant
> let (x: x, y: y) = foo  
> 
> Labels elsewhere are a different story and I do support the cosmetic addition 
> Chris Lattner sketched out here: 
> https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html
> 
> However this is about closures and not tuples, I don’t think this would 
> anyhow affect the removal of labels in tuple destructuring.
> 
> Plus I don’t see this to create an inconsistent in Swift, because as I 
> already said, labels in tuple destructuring are useless.
> 
> How come? I just illustrated their use. They help humans write correct code 
> by allowing the compiler to check an assertion that the human knows which 
> labels go with which positions in the tuple.

True, but the ability to define your own labels (instead of the API developer 
defining them for you) can make your code more readable. and hence maintainable.

Rien.

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

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

> I’m not arguing to remove all labels in Swift. Labels are great, this is a
> fact for sure. The point I was trying to make is that labels in tuples how
> either a meaning or not at all.
>
> // This is a shortcut for the tuple type `(x: Int, y: Int)`
> let foo = (x: 0, y: 0)
>
> // In this case the labels are only used for description,
> // they do not server any benefit here are most likely redundant
> let (x: x, y: y) = foo
>
> Labels elsewhere are a different story and I do support the cosmetic
> addition Chris Lattner sketched out here: https://lists.swift.org/
> pipermail/swift-evolution-announce/2016-July/000233.html
>
> However this is about closures and not tuples, I don’t think this would
> anyhow affect the removal of labels in tuple destructuring.
>
> Plus I don’t see this to create an inconsistent in Swift, because as I
> already said, labels in tuple destructuring are useless.
>
How come? I just illustrated their use. They help humans write correct code
by allowing the compiler to check an assertion that the human knows which
labels go with which positions in the tuple.
___
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]

Sorry I meant to say: “The point I was trying to make is that labels in tuples 
have either a meaning or not at all."

-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 09:28:45, Adrian Zubarev (adrian.zuba...@devandartist.com) 
schrieb:

The point I was trying to make is that labels in tuples how either a meaning or 
not at all.___
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 2:27 AM, David Hart  wrote:

>
> On 5 May 2017, at 09:24, Xiaodi Wu  wrote:
>
> On Fri, May 5, 2017 at 2:22 AM, David Hart  wrote:
>
>>
>> On 5 May 2017, at 07:56, Xiaodi Wu  wrote:
>>
>> 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/res
>> ources/posts/2015-07-19-tuples-swift-advanced-usage-best-practices.org
>>
>>
>> I do know and use tuple destructuring. But AFAIK, that’s not the syntax
>> Robert wants to ban: its the labels in that syntax. As he says:
>>
>> *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:*
>> *(z, y, x) = (x, z, y)*
>>
>
> I'n not saying that you don't know about tuple destructuring. I'm saying
> that the particular feature Robert wants to ban is covered in the article I
> linked to, which at least Google thinks is one of the most relevant
> articles on tuple destructuring in Swift. So, it's not as rare as Robert
> makes it out to be; plenty of people have talked about it.
>
>
> The article is still called "Advanced Usage”. Its difficult to state how
> rarely or common a feature is used but my intuition tells me this is a very
> rare feature. If we’ve discussed it on this list, it has escaped me. And
> I’ve never seen it in the wild.
>

I'd agree that using this feature to reorder things is likely to be very
rare. However, you've actually never seen someone destructure a tuple using
labels? That's surprising to me. I feel _guilty_ every time I destructure a
tuple knowingly not writing labels! It feels...risky.
___
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]

I’m not arguing to remove all labels in Swift. Labels are great, this is a fact 
for sure. The point I was trying to make is that labels in tuples how either a 
meaning or not at all.

// This is a shortcut for the tuple type `(x: Int, y: Int)`
let foo = (x: 0, y: 0)  

// In this case the labels are only used for description,  
// they do not server any benefit here are most likely redundant
let (x: x, y: y) = foo  
Labels elsewhere are a different story and I do support the cosmetic addition 
Chris Lattner sketched out here: 
https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html

However this is about closures and not tuples, I don’t think this would anyhow 
affect the removal of labels in tuple destructuring.

Plus I don’t see this to create an inconsistent in Swift, because as I already 
said, labels in tuple destructuring are useless.



-- 
Adrian Zubarev
Sent with Airmail

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

On Fri, May 5, 2017 at 2:04 AM, Adrian Zubarev 
 wrote:
Personally I don’t see the latter as an issue, at least not in that particular 
example of yours, because you can always look up the type of your labeled tuple.

That's an argument that can be made for nearly all labels in the language, is 
it not? Function argument labels could be entirely removed, by your argument, 
since parameter names are completely visible in the documentation and you can 
always just look it up. Consider the rationale behind revising SE-0111 
expressly to allow "cosmetic" labels. As I said, many languages don't have 
labels, but Swift does.

Is there any benefit gained from labels in tuple destructuring? let (x: x, y: 
y) is redundant to my eyes. If we ban reordering now, than I don’t see choosing 
different names in tuple destructuring as a strong argument of allowing labels 
there let (x: a, y: b). They’re literally the same as one would write comments 
inside the destructured tuple let (/* my x */ x, /* my y*/ y).

If you look in the C++ parts of the Swift compiler, that's the style for 
arguments in function calls where in Swift we use argument labels. Same idea. 
Your argument would remove most if not all labels from the language.



-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 08:36:20, Xiaodi Wu via swift-evolution 
(swift-evolution@swift.org) schrieb:

```
let tuple = (x: 1, y: 2)

// I, silly human, mistakenly think the elements in the tuple are
// `y` first, then `x`. I'm a confused human. Now I write:

let (y: y, x: x) = tuple
// Currently, does the right thing, even though I'm confused.

let (y: y, x: x) = tuple
// Without tuple reordering, this produces an error, which corrects my 
confusion.

let (y, x) = tuple
// Oops. I'm out of luck.
```

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

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

[David Hart via swift-evolution]

> On 5 May 2017, at 09:24, Xiaodi Wu  wrote:
> 
> On Fri, May 5, 2017 at 2:22 AM, David Hart  > wrote:
> 
>> On 5 May 2017, at 07:56, Xiaodi Wu > > wrote:
>> 
>> On Fri, May 5, 2017 at 12:54 AM, David Hart > > wrote:
>> 
>> 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.
>> 
>> 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
>>  
>> 
> 
> I do know and use tuple destructuring. But AFAIK, that’s not the syntax 
> Robert wants to ban: its the labels in that syntax. As he says:
> 
> 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:
> (z, y, x) = (x, z, y)
> 
> I'n not saying that you don't know about tuple destructuring. I'm saying that 
> the particular feature Robert wants to ban is covered in the article I linked 
> to, which at least Google thinks is one of the most relevant articles on 
> tuple destructuring in Swift. So, it's not as rare as Robert makes it out to 
> be; plenty of people have talked about it.

The article is still called "Advanced Usage”. Its difficult to state how rarely 
or common a feature is used but my intuition tells me this is a very rare 
feature. If we’ve discussed it on this list, it has escaped me. And I’ve never 
seen it in the wild.

>>> ~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 

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

[Xiaodi Wu via swift-evolution]

On Fri, May 5, 2017 at 2:14 AM, Xiaodi Wu  wrote:

> On Fri, May 5, 2017 at 1:44 AM, Robert Widmann 
> wrote:
>
>> I can see where you’re coming from, absolutely.  I don’t intend to remove
>> necessary semantic content labels can provide if I don’t have to.
>>
>> For the sake of expediency - and because even with labels you can
>> destructure into a label-less pattern, I’ll concede this point and remove
>> the section about removing labeled patterns from the draft on Github.
>>
>
> Without that chunk, I would be fine with the proposal. It removes a clever
> part of the language, but perhaps too clever and now rather unexpected,
> with the direction in which it's evolving.
>

I should add, there's an added benefit here. If you allow labels but remove
shuffling, there's a good chance that *unintentional* shuffles get called
out during migration. Boom, bugs fixed, better code. Swift saves the day.


>
>> ~Robert Widmann
>>
>> On May 5, 2017, at 2:35 AM, Xiaodi Wu  wrote:
>>
>> On Fri, May 5, 2017 at 1:31 AM, Xiaodi Wu  wrote:
>>
>>> On Fri, May 5, 2017 at 1:21 AM, Robert Widmann >> > wrote:
>>>
 Those labels anchored the reordering algorithm.  They guaranteed that
 structural typing thing I brought up where you had to consume all the
 labels in the type signature before you could continue, but that was where
 their semantic value ended.  Given an ordering invariant, what matters are
 the names *you* give to the values in the pattern.  Not the names
 given in, say, the return value of the function - which as part of the type
 are supposed to be irrelevant anyways.

>>>
>>> There's more to Swift's syntax than what's solely required for the
>>> compiler to parse it. There are also the bits we put in to help humans
>>> write correct code.
>>>
>>> This is one reason why SE-0111 was revised to permit "cosmetic" labels
>>> for functions after their type system significance was removed. With
>>> respect to tuples, I fully understand that if you remove the ability to
>>> reorder indices of a tuple, labels in tuple patterns won't "do"
>>> anything--other than assert that the poor human who's writing them has the
>>> tuple elements in the right order. But that's important. That's valuable.
>>>
>>
>> Put concretely:
>>
>> ```
>> let tuple = (x: 1, y: 2)
>>
>> // I, silly human, mistakenly think the elements in the tuple are
>> // `y` first, then `x`. I'm a confused human. Now I write:
>>
>> let (y: y, x: x) = tuple
>> // Currently, does the right thing, even though I'm confused.
>>
>> let (y: y, x: x) = tuple
>> // Without tuple reordering, this produces an error, which corrects my
>> confusion.
>>
>> let (y, x) = tuple
>> // Oops. I'm out of luck.
>> ```
>>
>> Enum cases are a different kettle of fish since the last round of
 proposals (specifically SE-0155).  Associated value clauses are no longer
 tuples.

 Thank you for digging up that blog about this too.  I hadn't seen that
 before I went into this - it came up because of code review related to some
 fallout from SE-110.

 ~Robert Widmann

 2017/05/05 2:09、Xiaodi Wu  のメッセージ:

 On Fri, May 5, 2017 at 1:01 AM, Robert Widmann <
 devteam.cod...@gmail.com> wrote:

>
>
> ~Robert Widmann
>
> 2017/05/05 1:42、Xiaodi Wu  のメッセージ:
>
> 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.
>
>
> They are both modeled by shuffles.  And we are spinning off into
> semantic weeds I'd rather not spin off into.  The core of your
> counterargument is the pattern change being bad for business.  Let's
> discuss that.
>
>
> 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 

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

[Xiaodi Wu via swift-evolution]

On Fri, May 5, 2017 at 2:22 AM, David Hart  wrote:

>
> On 5 May 2017, at 07:56, Xiaodi Wu  wrote:
>
> 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
>
>
> I do know and use tuple destructuring. But AFAIK, that’s not the syntax
> Robert wants to ban: its the labels in that syntax. As he says:
>
> *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:*
> *(z, y, x) = (x, z, y)*
>

I'n not saying that you don't know about tuple destructuring. I'm saying
that the particular feature Robert wants to ban is covered in the article I
linked to, which at least Google thinks is one of the most relevant
articles on tuple destructuring in Swift. So, it's not as rare as Robert
makes it out to be; plenty of people have talked about 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 

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

[David Hart via swift-evolution]

> On 5 May 2017, at 07:56, Xiaodi Wu  wrote:
> 
> On Fri, May 5, 2017 at 12:54 AM, David Hart  > wrote:
> 
> 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.
> 
> 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
>  
> 

I do know and use tuple destructuring. But AFAIK, that’s not the syntax Robert 
wants to ban: its the labels in that syntax. As he says:

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:
(z, y, x) = (x, z, y)

>> ~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 

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

[Xiaodi Wu via swift-evolution]

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

> Personally I don’t see the latter as an issue, at least not in that
> particular example of yours, because you can always look up the type of
> your labeled tuple.
>
That's an argument that can be made for nearly all labels in the language,
is it not? Function argument labels could be entirely removed, by your
argument, since parameter names are completely visible in the documentation
and you can always just look it up. Consider the rationale behind revising
SE-0111 expressly to allow "cosmetic" labels. As I said, many languages
don't have labels, but Swift does.

--
>
> Is there any benefit gained from labels in tuple destructuring? let (x:
> x, y: y) is redundant to my eyes. If we ban reordering now, than I don’t
> see choosing different names in tuple destructuring as a strong argument of
> allowing labels there let (x: a, y: b). They’re literally the same as one
> would write comments inside the destructured tuple let (/* my x */ x, /*
> my y*/ y).
>
If you look in the C++ parts of the Swift compiler, that's the style for
arguments in function calls where in Swift we use argument labels. Same
idea. Your argument would remove most if not all labels from the language.


>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 5. Mai 2017 um 08:36:20, Xiaodi Wu via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
> ```
> let tuple = (x: 1, y: 2)
>
> // I, silly human, mistakenly think the elements in the tuple are
> // `y` first, then `x`. I'm a confused human. Now I write:
>
> let (y: y, x: x) = tuple
> // Currently, does the right thing, even though I'm confused.
>
> let (y: y, x: x) = tuple
> // Without tuple reordering, this produces an error, which corrects my
> confusion.
>
> let (y, x) = tuple
> // Oops. I'm out of luck.
> ```
>
>
___
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 1:44 AM, Robert Widmann 
wrote:

> I can see where you’re coming from, absolutely.  I don’t intend to remove
> necessary semantic content labels can provide if I don’t have to.
>
> For the sake of expediency - and because even with labels you can
> destructure into a label-less pattern, I’ll concede this point and remove
> the section about removing labeled patterns from the draft on Github.
>

Without that chunk, I would be fine with the proposal. It removes a clever
part of the language, but perhaps too clever and now rather unexpected,
with the direction in which it's evolving.


> ~Robert Widmann
>
> On May 5, 2017, at 2:35 AM, Xiaodi Wu  wrote:
>
> On Fri, May 5, 2017 at 1:31 AM, Xiaodi Wu  wrote:
>
>> On Fri, May 5, 2017 at 1:21 AM, Robert Widmann 
>> wrote:
>>
>>> Those labels anchored the reordering algorithm.  They guaranteed that
>>> structural typing thing I brought up where you had to consume all the
>>> labels in the type signature before you could continue, but that was where
>>> their semantic value ended.  Given an ordering invariant, what matters are
>>> the names *you* give to the values in the pattern.  Not the names given
>>> in, say, the return value of the function - which as part of the type are
>>> supposed to be irrelevant anyways.
>>>
>>
>> There's more to Swift's syntax than what's solely required for the
>> compiler to parse it. There are also the bits we put in to help humans
>> write correct code.
>>
>> This is one reason why SE-0111 was revised to permit "cosmetic" labels
>> for functions after their type system significance was removed. With
>> respect to tuples, I fully understand that if you remove the ability to
>> reorder indices of a tuple, labels in tuple patterns won't "do"
>> anything--other than assert that the poor human who's writing them has the
>> tuple elements in the right order. But that's important. That's valuable.
>>
>
> Put concretely:
>
> ```
> let tuple = (x: 1, y: 2)
>
> // I, silly human, mistakenly think the elements in the tuple are
> // `y` first, then `x`. I'm a confused human. Now I write:
>
> let (y: y, x: x) = tuple
> // Currently, does the right thing, even though I'm confused.
>
> let (y: y, x: x) = tuple
> // Without tuple reordering, this produces an error, which corrects my
> confusion.
>
> let (y, x) = tuple
> // Oops. I'm out of luck.
> ```
>
> Enum cases are a different kettle of fish since the last round of
>>> proposals (specifically SE-0155).  Associated value clauses are no longer
>>> tuples.
>>>
>>> Thank you for digging up that blog about this too.  I hadn't seen that
>>> before I went into this - it came up because of code review related to some
>>> fallout from SE-110.
>>>
>>> ~Robert Widmann
>>>
>>> 2017/05/05 2:09、Xiaodi Wu  のメッセージ:
>>>
>>> On Fri, May 5, 2017 at 1:01 AM, Robert Widmann >> > wrote:
>>>


 ~Robert Widmann

 2017/05/05 1:42、Xiaodi Wu  のメッセージ:

 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.


 They are both modeled by shuffles.  And we are spinning off into
 semantic weeds I'd rather not spin off into.  The core of your
 counterargument is the pattern change being bad for business.  Let's
 discuss that.


 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 

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

[Adrian Zubarev via swift-evolution]

Personally I don’t see the latter as an issue, at least not in that particular 
example of yours, because you can always look up the type of your labeled tuple.

Is there any benefit gained from labels in tuple destructuring? let (x: x, y: 
y) is redundant to my eyes. If we ban reordering now, than I don’t see choosing 
different names in tuple destructuring as a strong argument of allowing labels 
there let (x: a, y: b). They’re literally the same as one would write comments 
inside the destructured tuple let (/* my x */ x, /* my y*/ y).



-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 08:36:20, Xiaodi Wu via swift-evolution 
(swift-evolution@swift.org) schrieb:

```
let tuple = (x: 1, y: 2)

// I, silly human, mistakenly think the elements in the tuple are
// `y` first, then `x`. I'm a confused human. Now I write:

let (y: y, x: x) = tuple
// Currently, does the right thing, even though I'm confused.

let (y: y, x: x) = tuple
// Without tuple reordering, this produces an error, which corrects my 
confusion.

let (y, x) = tuple
// Oops. I'm out of luck.
```
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Goffredo Marocchi via swift-evolution]

That is weird indeed, there is need of more argument labels, like argument 
labels back in stored closures and callbacks, not even less argument labels all 
around :/.

-1 as a corner case of the language throws the baby out with the bathwater.

Sent from my iPhone

> On 5 May 2017, at 05:53, Xiaodi Wu via swift-evolution 
>  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-
> 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 

Re: [swift-evolution] [Review] SE-0175 Package Manager Revised Dependency Resolution

[Martin Waitz via swift-evolution]

> * What is your evaluation of the proposal?

I’m in favour of this proposal.
It solves the problems I have with the current behaviour of the swift package 
manager.

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

yes.
While the existing auto-pinning feature can be used to get reproducible 
dependency versions,
it has some deficiencies which make it more complicated than required for the 
common cases without really solving the more exotic use cases.
Package pinning vs. requiring a specific revision in Package.swift also felt 
like two overlapping features without a clear motivation for one versus the 
other.

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

yes.
It focuses on doing one thing well without precluding other user use cases.
The new behaviour defaults does the right thing(TM) for the common use cases 
and is easily explained.
Especially now that we are already able to require specific versions within 
Package.swift, SE-0150+SE-0175 provide a nice set of orthogonal features.

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

Never used a package manager with this kind of dependency resolution and always 
wanted to have one.

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

Took part in the discussions for SE-0145 and now read SE-0175.

— 
Martin
___
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]

What others have noted, in addition to our Twitter thread, is that this 
proposal has revealed the need for diagnostics about shadowing.  There are 
currently two boundaries in Swift along which we allow shadowing in the same 
scope: Function arguments and patterns.  If we can close both of those 
loopholes I would be much less skittish about labels.

~Robert Widmann

> On May 5, 2017, at 2:35 AM, Xiaodi Wu  wrote:
> 
> On Fri, May 5, 2017 at 1:31 AM, Xiaodi Wu  > wrote:
> On Fri, May 5, 2017 at 1:21 AM, Robert Widmann  > wrote:
> Those labels anchored the reordering algorithm.  They guaranteed that 
> structural typing thing I brought up where you had to consume all the labels 
> in the type signature before you could continue, but that was where their 
> semantic value ended.  Given an ordering invariant, what matters are the 
> names you give to the values in the pattern.  Not the names given in, say, 
> the return value of the function - which as part of the type are supposed to 
> be irrelevant anyways.
> 
> There's more to Swift's syntax than what's solely required for the compiler 
> to parse it. There are also the bits we put in to help humans write correct 
> code.
> 
> This is one reason why SE-0111 was revised to permit "cosmetic" labels for 
> functions after their type system significance was removed. With respect to 
> tuples, I fully understand that if you remove the ability to reorder indices 
> of a tuple, labels in tuple patterns won't "do" anything--other than assert 
> that the poor human who's writing them has the tuple elements in the right 
> order. But that's important. That's valuable.
> 
> Put concretely:
> 
> ```
> let tuple = (x: 1, y: 2)
> 
> // I, silly human, mistakenly think the elements in the tuple are
> // `y` first, then `x`. I'm a confused human. Now I write:
> 
> let (y: y, x: x) = tuple
> // Currently, does the right thing, even though I'm confused.
> 
> let (y: y, x: x) = tuple
> // Without tuple reordering, this produces an error, which corrects my 
> confusion.
> 
> let (y, x) = tuple
> // Oops. I'm out of luck.
> ```
> 
> Enum cases are a different kettle of fish since the last round of proposals 
> (specifically SE-0155).  Associated value clauses are no longer tuples.
> 
> Thank you for digging up that blog about this too.  I hadn't seen that before 
> I went into this - it came up because of code review related to some fallout 
> from SE-110.
> 
> ~Robert Widmann
> 
> 2017/05/05 2:09、Xiaodi Wu > 
> のメッセージ:
> 
>> On Fri, May 5, 2017 at 1:01 AM, Robert Widmann > > wrote:
>> 
>> 
>> ~Robert Widmann
>> 
>> 2017/05/05 1:42、Xiaodi Wu > 
>> のメッセージ:
>> 
>>> 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.
>> 
>> They are both modeled by shuffles.  And we are spinning off into semantic 
>> weeds I'd rather not spin off into.  The core of your counterargument is the 
>> pattern change being bad for business.  Let's discuss that. 
>> 
>>> 
 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"
>>> ```
>>> 

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

[Robert Widmann via swift-evolution]

To clarify for the root.  Disregard the “Detailed Design” section attached to 
this email.  The proposal on Github no longer seeks to remove labeled tuple 
patterns from the language.


> On May 4, 2017, at 10:14 PM, Robert Widmann  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

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

[Robert Widmann via swift-evolution]

I can see where you’re coming from, absolutely.  I don’t intend to remove 
necessary semantic content labels can provide if I don’t have to.  

For the sake of expediency - and because even with labels you can destructure 
into a label-less pattern, I’ll concede this point and remove the section about 
removing labeled patterns from the draft on Github.

~Robert Widmann

> On May 5, 2017, at 2:35 AM, Xiaodi Wu  wrote:
> 
> On Fri, May 5, 2017 at 1:31 AM, Xiaodi Wu  > wrote:
> On Fri, May 5, 2017 at 1:21 AM, Robert Widmann  > wrote:
> Those labels anchored the reordering algorithm.  They guaranteed that 
> structural typing thing I brought up where you had to consume all the labels 
> in the type signature before you could continue, but that was where their 
> semantic value ended.  Given an ordering invariant, what matters are the 
> names you give to the values in the pattern.  Not the names given in, say, 
> the return value of the function - which as part of the type are supposed to 
> be irrelevant anyways.
> 
> There's more to Swift's syntax than what's solely required for the compiler 
> to parse it. There are also the bits we put in to help humans write correct 
> code.
> 
> This is one reason why SE-0111 was revised to permit "cosmetic" labels for 
> functions after their type system significance was removed. With respect to 
> tuples, I fully understand that if you remove the ability to reorder indices 
> of a tuple, labels in tuple patterns won't "do" anything--other than assert 
> that the poor human who's writing them has the tuple elements in the right 
> order. But that's important. That's valuable.
> 
> Put concretely:
> 
> ```
> let tuple = (x: 1, y: 2)
> 
> // I, silly human, mistakenly think the elements in the tuple are
> // `y` first, then `x`. I'm a confused human. Now I write:
> 
> let (y: y, x: x) = tuple
> // Currently, does the right thing, even though I'm confused.
> 
> let (y: y, x: x) = tuple
> // Without tuple reordering, this produces an error, which corrects my 
> confusion.
> 
> let (y, x) = tuple
> // Oops. I'm out of luck.
> ```
> 
> Enum cases are a different kettle of fish since the last round of proposals 
> (specifically SE-0155).  Associated value clauses are no longer tuples.
> 
> Thank you for digging up that blog about this too.  I hadn't seen that before 
> I went into this - it came up because of code review related to some fallout 
> from SE-110.
> 
> ~Robert Widmann
> 
> 2017/05/05 2:09、Xiaodi Wu > 
> のメッセージ:
> 
>> On Fri, May 5, 2017 at 1:01 AM, Robert Widmann > > wrote:
>> 
>> 
>> ~Robert Widmann
>> 
>> 2017/05/05 1:42、Xiaodi Wu > 
>> のメッセージ:
>> 
>>> 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.
>> 
>> They are both modeled by shuffles.  And we are spinning off into semantic 
>> weeds I'd rather not spin off into.  The core of your counterargument is the 
>> pattern change being bad for business.  Let's discuss that. 
>> 
>>> 
 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"
>>> ```
>>> 

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

[Rien via swift-evolution]

I think your misunderstanding helped a lot of people understand what is at 
issue here :-)

It did for me!

+1


Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift






> On 05 May 2017, at 08:33, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I’m aware what a label is, I just had a small misunderstanding about nested 
> destructuring. ;-)
> 
> Issue solved for me.
> 
> let (a, b /* inner tuple */) = tuple
> 
> let (_, (x, y)) = tuple
> 
> +1 I don’t mind this change at all.
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 5. Mai 2017 um 08:14:10, Xiaodi Wu (xiaodi...@gmail.com) schrieb:
> 
>> On Fri, May 5, 2017 at 1:12 AM, Adrian Zubarev 
>>  wrote:
>> Oh pardon, on the first glance I didn’t realized the issue with that example.
>> 
>> Here is an updated example that would work:
>> 
>> let (first, second: (x, y)): (first: Int, second: (x: Int, y: Int)) = tuple
>> 
>> This should work right?
>> 
>> No, again, this would be banned. You are using a label (a thing that ends in 
>> a colon) inside a tuple pattern (a thing between parenthesis that comes 
>> after "let").
>>  
>> It’s assigning the inner tuple to second while also creating two additional 
>> constants from the inner tuple. I know this is redundant and can be used as 
>> second.x, but this should work like right, because it’s nested tuple 
>> destructuring? If we’d use var instead of let then x would contain the value 
>> assigned from the inner tuple, but it would be completely independent from 
>> the new second tuple variable.
>> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 5. Mai 2017 um 08:04:07, Xiaodi Wu (xiaodi...@gmail.com) schrieb:
>> 
>>> let (first: a, second: (x: b, y: c)): (first: Int, second: (x: Int, y: 
>>> Int)) = tuple // fine, unaffected
>>> This would be banned. You are using labels (things ending with a colon) in 
>>> a pattern (the stuff that comes after the word "let").
>> 
> 
> ___
> 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]

On Fri, May 5, 2017 at 1:31 AM, Xiaodi Wu  wrote:

> On Fri, May 5, 2017 at 1:21 AM, Robert Widmann 
> wrote:
>
>> Those labels anchored the reordering algorithm.  They guaranteed that
>> structural typing thing I brought up where you had to consume all the
>> labels in the type signature before you could continue, but that was where
>> their semantic value ended.  Given an ordering invariant, what matters are
>> the names *you* give to the values in the pattern.  Not the names given
>> in, say, the return value of the function - which as part of the type are
>> supposed to be irrelevant anyways.
>>
>
> There's more to Swift's syntax than what's solely required for the
> compiler to parse it. There are also the bits we put in to help humans
> write correct code.
>
> This is one reason why SE-0111 was revised to permit "cosmetic" labels for
> functions after their type system significance was removed. With respect to
> tuples, I fully understand that if you remove the ability to reorder
> indices of a tuple, labels in tuple patterns won't "do" anything--other
> than assert that the poor human who's writing them has the tuple elements
> in the right order. But that's important. That's valuable.
>

Put concretely:

```
let tuple = (x: 1, y: 2)

// I, silly human, mistakenly think the elements in the tuple are
// `y` first, then `x`. I'm a confused human. Now I write:

let (y: y, x: x) = tuple
// Currently, does the right thing, even though I'm confused.

let (y: y, x: x) = tuple
// Without tuple reordering, this produces an error, which corrects my
confusion.

let (y, x) = tuple
// Oops. I'm out of luck.
```

Enum cases are a different kettle of fish since the last round of proposals
>> (specifically SE-0155).  Associated value clauses are no longer tuples.
>>
>> Thank you for digging up that blog about this too.  I hadn't seen that
>> before I went into this - it came up because of code review related to some
>> fallout from SE-110.
>>
>> ~Robert Widmann
>>
>> 2017/05/05 2:09、Xiaodi Wu  のメッセージ:
>>
>> On Fri, May 5, 2017 at 1:01 AM, Robert Widmann 
>> wrote:
>>
>>>
>>>
>>> ~Robert Widmann
>>>
>>> 2017/05/05 1:42、Xiaodi Wu  のメッセージ:
>>>
>>> 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.
>>>
>>>
>>> They are both modeled by shuffles.  And we are spinning off into
>>> semantic weeds I'd rather not spin off into.  The core of your
>>> counterargument is the pattern change being bad for business.  Let's
>>> discuss that.
>>>
>>>
>>> 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.
>>>
>>>
>>> This is a reordering.  Banned.  End of story.  This code is fragile and
>>> demonstrates a key reason why we need to enforce an ordering invariant.
>>>
>>>
>>>

 And how about 

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

[Adrian Zubarev via swift-evolution]

I’m aware what a label is, I just had a small misunderstanding about nested 
destructuring. ;-)

Issue solved for me.

let (a, b /* inner tuple */) = tuple

let (_, (x, y)) = tuple
+1 I don’t mind this change at all.



-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 08:14:10, Xiaodi Wu (xiaodi...@gmail.com) schrieb:

On Fri, May 5, 2017 at 1:12 AM, Adrian Zubarev 
 wrote:
Oh pardon, on the first glance I didn’t realized the issue with that example.

Here is an updated example that would work:

let (first, second: (x, y)): (first: Int, second: (x: Int, y: Int)) = tuple
This should work right?

No, again, this would be banned. You are using a label (a thing that ends in a 
colon) inside a tuple pattern (a thing between parenthesis that comes after 
"let").
 
It’s assigning the inner tuple to second while also creating two additional 
constants from the inner tuple. I know this is redundant and can be used as 
second.x, but this should work like right, because it’s nested tuple 
destructuring? If we’d use var instead of let then x would contain the value 
assigned from the inner tuple, but it would be completely independent from the 
new second tuple variable.



-- 
Adrian Zubarev
Sent with Airmail

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

let (first: a, second: (x: b, y: c)): (first: Int, second: (x: Int, y: Int)) = 
tuple // fine, unaffected
This would be banned. You are using labels (things ending with a colon) in a 
pattern (the stuff that comes after the word "let").

___
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 1:21 AM, Robert Widmann 
wrote:

> Those labels anchored the reordering algorithm.  They guaranteed that
> structural typing thing I brought up where you had to consume all the
> labels in the type signature before you could continue, but that was where
> their semantic value ended.  Given an ordering invariant, what matters are
> the names *you* give to the values in the pattern.  Not the names given
> in, say, the return value of the function - which as part of the type are
> supposed to be irrelevant anyways.
>

There's more to Swift's syntax than what's solely required for the compiler
to parse it. There are also the bits we put in to help humans write correct
code.

This is one reason why SE-0111 was revised to permit "cosmetic" labels for
functions after their type system significance was removed. With respect to
tuples, I fully understand that if you remove the ability to reorder
indices of a tuple, labels in tuple patterns won't "do" anything--other
than assert that the poor human who's writing them has the tuple elements
in the right order. But that's important. That's valuable.

Enum cases are a different kettle of fish since the last round of proposals
> (specifically SE-0155).  Associated value clauses are no longer tuples.
>
> Thank you for digging up that blog about this too.  I hadn't seen that
> before I went into this - it came up because of code review related to some
> fallout from SE-110.
>
> ~Robert Widmann
>
> 2017/05/05 2:09、Xiaodi Wu  のメッセージ:
>
> On Fri, May 5, 2017 at 1:01 AM, Robert Widmann 
> wrote:
>
>>
>>
>> ~Robert Widmann
>>
>> 2017/05/05 1:42、Xiaodi Wu  のメッセージ:
>>
>> 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.
>>
>>
>> They are both modeled by shuffles.  And we are spinning off into semantic
>> weeds I'd rather not spin off into.  The core of your counterargument is
>> the pattern change being bad for business.  Let's discuss that.
>>
>>
>> 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.
>>
>>
>> This is a reordering.  Banned.  End of story.  This code is fragile and
>> demonstrates a key reason why we need to enforce an ordering invariant.
>>
>>
>>
>>>
>>> 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 

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

[Robert Widmann via swift-evolution]

Those labels anchored the reordering algorithm.  They guaranteed that 
structural typing thing I brought up where you had to consume all the labels in 
the type signature before you could continue, but that was where their semantic 
value ended.  Given an ordering invariant, what matters are the names you give 
to the values in the pattern.  Not the names given in, say, the return value of 
the function - which as part of the type are supposed to be irrelevant anyways.

Enum cases are a different kettle of fish since the last round of proposals 
(specifically SE-0155).  Associated value clauses are no longer tuples.

Thank you for digging up that blog about this too.  I hadn't seen that before I 
went into this - it came up because of code review related to some fallout from 
SE-110.

~Robert Widmann

2017/05/05 2:09、Xiaodi Wu  のメッセージ:

>> On Fri, May 5, 2017 at 1:01 AM, Robert Widmann  
>> wrote:
>> 
>> 
>> ~Robert Widmann
>> 
>> 2017/05/05 1:42、Xiaodi Wu  のメッセージ:
>> 
 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.
>> 
>> They are both modeled by shuffles.  And we are spinning off into semantic 
>> weeds I'd rather not spin off into.  The core of your counterargument is the 
>> pattern change being bad for business.  Let's discuss that. 
>> 
>>> 
> 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.
>> 
>> This is a reordering.  Banned.  End of story.  This code is fragile and 
>> demonstrates a key reason why we need to enforce an ordering invariant.
>> 
>>>  
 
>> 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 

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

[Xiaodi Wu via swift-evolution]

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

> Oh pardon, on the first glance I didn’t realized the issue with that
> example.
>
> Here is an updated example that would work:
>
> let (first, second: (x, y)): (first: Int, second: (x: Int, y: Int)) = tuple
>
> This should work right?
>
No, again, this would be banned. You are using a label (a thing that ends
in a colon) inside a tuple pattern (a thing between parenthesis that comes
after "let").


> It’s assigning the inner tuple to second while also creating two
> additional constants from the inner tuple. I know this is redundant and can
> be used as second.x, but this should work like right, because it’s nested
> tuple destructuring? If we’d use var instead of let then x would contain
> the value assigned from the inner tuple, but it would be completely
> independent from the new second tuple variable.
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 5. Mai 2017 um 08:04:07, Xiaodi Wu (xiaodi...@gmail.com) schrieb:
>
> let (first: a, second: (x: b, y: c)): (first: Int, second: (x: Int, y: Int)) 
> = tuple // fine, unaffected
>
> This would be banned. You are using labels (things ending with a colon) in
> a pattern (the stuff that comes after the word "let").
>
>
___
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]

Oh pardon, on the first glance I didn’t realized the issue with that example.

Here is an updated example that would work:

let (first, second: (x, y)): (first: Int, second: (x: Int, y: Int)) = tuple
This should work right? It’s assigning the inner tuple to second while also 
creating two additional constants from the inner tuple. I know this is 
redundant and can be used as second.x, but this should work like right, because 
it’s nested tuple destructuring? If we’d use var instead of let then x would 
contain the value assigned from the inner tuple, but it would be completely 
independent from the new second tuple variable.



-- 
Adrian Zubarev
Sent with Airmail

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

let (first: a, second: (x: b, y: c)): (first: Int, second: (x: Int, y: Int)) = 
tuple // fine, unaffected
This would be banned. You are using labels (things ending with a colon) in a 
pattern (the stuff that comes after the word "let").
___
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 1:01 AM, Robert Widmann 
wrote:

>
>
> ~Robert Widmann
>
> 2017/05/05 1:42、Xiaodi Wu  のメッセージ:
>
> 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.
>
>
> They are both modeled by shuffles.  And we are spinning off into semantic
> weeds I'd rather not spin off into.  The core of your counterargument is
> the pattern change being bad for business.  Let's discuss that.
>
>
> 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.
>
>
> This is a reordering.  Banned.  End of story.  This code is fragile and
> demonstrates a key reason why we need to enforce an ordering invariant.
>
>
>
>>
>> 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.
>
>
> The intent at the time may have been to treat tuples as a kind of
> structurally-typed thing, but shadowing concerns and reordering in patterns
> means this kind of relabeling can be abused and shouldn't be trusted as a
> kind of structural invariant in a pattern - as we seem to agree.  To me,
> labels in tuple types provide a means of defining custom projections out of
> the tuple, nothing more.  In patterns, I don't see a reason for them.
>

We can agree that relabeling can be abused, but it does not stand to reason
that labeling (i.e. the correct, unchanged label) has no role in tuple
patterns. Again, it serves as 

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

[Xiaodi Wu via swift-evolution]

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

> Just to double check, here is the updated version of my code snippet on
> how it would look like if this proposal will be accepted.
>
> let a: (x: Int, y: Int) = (1, 2)
> var b: (y: Int, x: Int) = a
>
> This would be banned. It involves reordering arguments.


> Label swap while destructuring:
>
> let tuple: (first: Int, second: (x: Int, y: Int)) = (0, (1, 2))
>
> let (first: a, second: (x: b, y: c)): (first: Int, second: (x: Int, y: Int)) 
> = tuple // fine, unaffected
>
> This would be banned. You are using labels (things ending with a colon) in
a pattern (the stuff that comes after the word "let").

let (second: (x: b, y: c), first: a): (second: (x: Int, y: Int),
first: Int) = tuple // will the rendering be banned or not?
>
> This would also be banned.


>  Is this correct now?
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 5. Mai 2017 um 07:53:51, Xiaodi Wu (xiaodi...@gmail.com) schrieb:
>
> 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

[Robert Widmann via swift-evolution]

~Robert Widmann

2017/05/05 1:42、Xiaodi Wu  のメッセージ:

>> 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.

They are both modeled by shuffles.  And we are spinning off into semantic weeds 
I'd rather not spin off into.  The core of your counterargument is the pattern 
change being bad for business.  Let's discuss that. 

> 
>>> 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.

This is a reordering.  Banned.  End of story.  This code is fragile and 
demonstrates a key reason why we need to enforce an ordering invariant.

>  
>> 
 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.

The intent at the time may have been to treat tuples as a kind of 
structurally-typed thing, but shadowing concerns and reordering in patterns 
means this kind of relabeling can be abused and shouldn't be trusted as a kind 
of structural invariant in a pattern - as we seem to agree.  To me, labels in 
tuple types provide a means of defining custom projections out of the tuple, 
nothing more.  In patterns, I don't see a reason for them.

> 
>> 
>> ~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 

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

[Adrian Zubarev via swift-evolution]

Just to double check, here is the updated version of my code snippet on how it 
would look like if this proposal will be accepted.

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

let tuple: (first: Int, second: (x: Int, y: Int)) = (0, (1, 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 // will the rendering be banned or not?
Is this correct now?



-- 
Adrian Zubarev
Sent with Airmail

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

On Fri, May 5, 2017 at 12:52 AM, Adrian Zubarev 
 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 
 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, Xiaodi Wu  wrote:

> 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.
>

I should add, it boggles the mind that you would claim that people will
have never heard of this before today. It's been discussed _on this very
list_!
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution