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

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

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

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

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

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

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

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 n

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

> 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 > mailto:swift-evolution@swift.org>> wrote: > >> On the contrary, this is precisely what it means to

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

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 precis

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

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 be

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

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

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

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 a

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

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,

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

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 tuple

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

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 shor

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

> 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

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

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

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

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

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

> 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

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

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.

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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

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 1

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

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

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

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

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

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 a

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

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 co

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

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 al

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

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

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

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.

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

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 sec

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

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

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

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 swif

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

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

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

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

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

> 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

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

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 dec

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

* 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

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

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

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

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 >

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

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 d

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

> 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 >> mailto:swift-evolution@swift.org>> wrote: >> >> Thanks for your feedback, e

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

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

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

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

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

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

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

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.

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

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 percolat

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

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 dep

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

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 T

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

> 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

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

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 additiv

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

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

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

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

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

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 consump

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

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

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

The identifier after a colon is *never* a type in any pattern matching, and there's no need of which I'm aware to support type annotations in pattern matching. We put colons after labels, and the current syntax is perfectly consistent here. What is the defect you're trying to cure? On Fri, May 5, 2

[swift-evolution] [Accepted] SE-0174: Change filter to return an associated type

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0174-filter-range-replaceable.md Hello Swift Community, The review of SE-0174 "Change filter to return an associated type” ran from April 28...May 3, 2017. The proposal is accepted. Thank you to everyone who particip