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

Thanks, I just got the point: This is a war between Smalltalk and the world. In Smalltalk, function is not a type: function's signature include attributes name, but Type not,. The method Smalltalk treat function, is opposite to the normal method human see the world. For exam: We just need

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

On Fri, May 5, 2017 at 4:00 PM Xiaodi Wu wrote: > 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 >

Re: [swift-evolution] Ownership on protocol property requirements

LGTM! I'd go ahead with opening a PR. Time is running out! > On 8 May 2017, at 14:40, Greg Spiers wrote: > >> On Mon, May 8, 2017 at 7:57 AM, David Hart wrote: >> Sounds great! It should be an easy one to get through, > > Thanks David, appreciate it :)

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

> On May 8, 2017, at 4:17 PM, Tony Allevato wrote: > > > > On Mon, May 8, 2017 at 2:11 PM Matthew Johnson > wrote: >> On May 8, 2017, at 4:02 PM, Tony Allevato >

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

On Mon, May 8, 2017 at 2:11 PM Matthew Johnson wrote: > On May 8, 2017, at 4:02 PM, Tony Allevato wrote: > > On Sat, May 6, 2017 at 4:17 PM Chris Lattner wrote: > >> On May 5, 2017, at 11:33 AM, Tony Allevato via

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

> On May 8, 2017, at 4:02 PM, Tony Allevato wrote: > > On Sat, May 6, 2017 at 4:17 PM Chris Lattner > wrote: > On May 5, 2017, at 11:33 AM, Tony Allevato via swift-evolution >

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

On Sat, May 6, 2017 at 4:17 PM Chris Lattner wrote: > On May 5, 2017, at 11:33 AM, Tony Allevato via swift-evolution < > swift-evolution@swift.org> wrote: > > > >> >> Can the opt-in conformance be declared in an extension? If so, can the >> extension be in a different

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

On Sat, May 6, 2017 at 9:21 PM Brent Royal-Gordon wrote: > [Re-sending with minor edits since this didn't initially go to the list.] > > > On May 5, 2017, at 3:25 PM, Tony Allevato via swift-evolution < > swift-evolution@swift.org> wrote: > > > > Hi Tony, this is called

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

> On May 8, 2017, at 3:17 PM, Michael Ilseman via swift-evolution > wrote: > > If an extension on your type declares a hashValue property, what should be > the semantics? Is that an error (conflicts with default provided one), or is > that one used? How does

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

If an extension on your type declares a hashValue property, what should be the semantics? Is that an error (conflicts with default provided one), or is that one used? > On May 4, 2017, at 3:20 PM, Andrew Bennett via swift-evolution > wrote: > > That's correct,

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

- What is your evaluation of the proposal? +1 - Is the problem being addressed significant enough to warrant a change to Swift?Yes - Does this proposal fit well with the feel and direction of Swift?I think so. - If you have used other languages or libraries with a similar feature, how do you feel

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

> On May 4, 2017, at 8: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

Re: [swift-evolution] Overriding specific methods when adopting protocols with extension

Hey Björn, I haven't seen any conversation on this. The proposal looked to present 2 possible implementation approaches pretty well, and the feedback thread was pretty light. Maybe someone from the core team can comment on the next step? Since it is potentially source breaking, I hope it makes it

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

> On May 7, 2017, at 10:41 AM, Paul Cantrell wrote: > > >> On May 7, 2017, at 6:01 AM, Jean-Daniel > > wrote: >> >>> >>> Le 7 mai 2017 à 03:54, Paul Cantrell via swift-evolution >>>

Re: [swift-evolution] optional variable with ternary operator

Well, you’re not allowed to compare optionals any more. You can try binding the value to an Int, so that it’s not an optional anymore: if let number = number { let result = number > 0 ? 1 : 2 } Either way, you’ll have to decide what you think should happen when number is nil. Saagar

[swift-evolution] optional variable with ternary operator

Hey, i am using ternary operator with optional variable. like below ex. > *var number:Int?**let result = number > 0 ? 1 : 2 * *here i am getting this waring : comparison operators with optionals were removed from the Swift Standard Library. Consider refactoring the code to use the

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

On Sun, May 7, 2017 at 2:04 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > Actually, `swapAt` does have a precondition that the elements differ. Looking at the source code , the

Re: [swift-evolution] Overriding specific methods when adopting protocols with extension

Hi Brian, is the override proposal still in the making? Kind Regards, Björn On Thu, Mar 23, 2017 at 4:24 PM, Brian King via swift-evolution < swift-evolution@swift.org> wrote: > Hey Iman, This is a known bug SR-103. It certainly has caught a few people > off guard. Dale Buckley is working on an

Re: [swift-evolution] Ownership on protocol property requirements

On Mon, May 8, 2017 at 7:57 AM, David Hart wrote: > Sounds great! It should be an easy one to get through, Thanks David, appreciate it :) I've created a draft of the proposal. Any feedback would be very welcome. I wasn't sure if there was an effect on ABI stability or API

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

On 05.05.2017 19:38, 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

Re: [swift-evolution] Ownership on protocol property requirements

On Mon, May 8, 2017 at 2:52 AM, Goffredo Marocchi wrote: > > > Sent from my iPhone > > On 8 May 2017, at 08:44, Xiaodi Wu wrote: > > On Mon, May 8, 2017 at 2:40 AM, Goffredo Marocchi via swift-evolution < > swift-evolution@swift.org> wrote: > >> I can

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

On Mon, May 8, 2017 at 4:01 AM, André Videla wrote: > > Why do you feel this clever puzzle needs to be eliminated? > I dont feel like it needs to be eliminated. > > > Do you have any evidence that this shows up in real-world code? > No. > > > For instance, I have had to

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

On Mon, May 8, 2017 at 3:08 AM, Brent Royal-Gordon wrote: > On May 8, 2017, at 12:09 AM, Xiaodi Wu wrote: > > Highly disagree. Consistency teaches us that variables can come after a > colon. > > > But not normally in a declaration. > > On May 8,

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

> Why do you feel this clever puzzle needs to be eliminated? I dont feel like it needs to be eliminated. > Do you have any evidence that this shows up in real-world code? No. > For instance, I have had to use the name `T` at one point, because I was modeling something where `t` means a totally

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

On Mon, May 8, 2017 at 3:35 AM, André Videla wrote: > By the way, it seems that the only way to get rid of this clever puzzle is > to enforce uppercase for the first letter of type identifiers and lower > case for values identifiers. > Why do you feel this clever puzzle

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

I just realized this message was not sent to evolution -- Forwarded message -- From: André Videla Date: 2017-05-08 9:51 GMT+02:00 Subject: Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles To: Xiaodi Wu Let me

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

On Mon, May 8, 2017 at 2:51 AM, André Videla wrote: > Let me show you: > > assume we have this data type which is just a pair of Ints > > enum Pair { > > case point(x: Int, y: Int) > > } > > and see how Swift allows us to deconstruct it: > > if case .point(let x, let

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

By the way, it seems that the only way to get rid of this clever puzzle is to enforce uppercase for the first letter of type identifiers and lower case for values identifiers. 2017-05-08 10:24 GMT+02:00 Adrian Zubarev via swift-evolution < swift-evolution@swift.org>: > I still have to disagree

Re: [swift-evolution] Ownership on protocol property requirements

On Mon, May 8, 2017 at 8:52 AM, Goffredo Marocchi via swift-evolution wrote: > > > > Sent from my iPhone > > On 8 May 2017, at 08:44, Xiaodi Wu wrote: > > On Mon, May 8, 2017 at 2:40 AM, Goffredo Marocchi via swift-evolution >

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

I still have to disagree on that. Tuple patterns are not consistent in Swift. Here is a small proof of my claim: enum Foo { case a(b: Int) } switch Foo.a(b: 10) { case .a(b: let x): print(x) } let tuple = (x: 2, y: 20) switch tuple { case (x: let a, y: let b):

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

> On May 8, 2017, at 12:09 AM, Xiaodi Wu wrote: > > Highly disagree. Consistency teaches us that variables can come after a colon. But not normally in a declaration. > On May 8, 2017, at 12:28 AM, Xiaodi Wu wrote: > > Yes, Robert came up with a very

Re: [swift-evolution] Ownership on protocol property requirements

Sent from my iPhone > On 8 May 2017, at 08:44, Xiaodi Wu wrote: > >> On Mon, May 8, 2017 at 2:40 AM, Goffredo Marocchi via swift-evolution >> wrote: >> I can understand that, I am just wary of "let's do a partially detrimental >> change > >

Re: [swift-evolution] Ownership on protocol property requirements

On Mon, May 8, 2017 at 2:40 AM, Goffredo Marocchi via swift-evolution < swift-evolution@swift.org> wrote: > I can understand that, I am just wary of "let's do a partially detrimental > change > The key here is that there is no detriment to this change. There's no functionality that's being

Re: [swift-evolution] Ownership on protocol property requirements

I can understand that, I am just wary of "let's do a partially detrimental change no... we will... we will make it proper someday" kind of changes as they seldom work out. Argument labels for stored closures and callbacks are still lost for example :/... Also, while here we keep pushing things

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

On Mon, May 8, 2017 at 2:15 AM, David Hart wrote: > > On 8 May 2017, at 09:09, Xiaodi Wu wrote: > > On Mon, May 8, 2017 at 12:16 AM, David Hart wrote: > >> >> On 7 May 2017, at 00:21, Xiaodi Wu via swift-evolution < >>

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

On Mon, May 8, 2017 at 1:30 AM, Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote: > Exactly, everything else is simply an excuse and nothing more. Tuple > destructuring is not even aligned to enum case patterns at all, because it > only uses the shorthand version and does not

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

> On 8 May 2017, at 09:09, Xiaodi Wu wrote: > > On Mon, May 8, 2017 at 12:16 AM, David Hart > wrote: > > On 7 May 2017, at 00:21, Xiaodi Wu via swift-evolution > >

Re: [swift-evolution] Ownership on protocol property requirements

> On 8 May 2017, at 09:03, Goffredo Marocchi wrote: > > Over my dead body --random list dweller ;) > > Seriously though, I think the labels should be made to matter not removed if > they do not matter now. I think this goes to a path where we should not take > protocols as

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

On Mon, May 8, 2017 at 12:16 AM, David Hart wrote: > > On 7 May 2017, at 00:21, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > To which human would it be misleading? > > To the writer? No, because the compiler will warn you right away. By the > time

Re: [swift-evolution] Ownership on protocol property requirements

Over my dead body --random list dweller ;) Seriously though, I think the labels should be made to matter not removed if they do not matter now. I think this goes to a path where we should not take protocols as they should be true contracts for the API in question (default method in protocols

Re: [swift-evolution] Ownership on protocol property requirements

Sounds great! It should be an easy one to get through, > On 8 May 2017, at 08:35, Greg Spiers wrote: > > > > On Mon, May 8, 2017 at 6:26 AM, David Hart via swift-evolution > > wrote: > > > On 7 May 2017, at

Re: [swift-evolution] Ownership on protocol property requirements

On Mon, May 8, 2017 at 6:26 AM, David Hart via swift-evolution < swift-evolution@swift.org> wrote: > > > On 7 May 2017, at 20:12, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > Today these keywords have no meaning inside a protocol, so clearly it > should be an error to

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

Exactly, everything else is simply an excuse and nothing more. Tuple destructuring is not even aligned to enum case patterns at all, because it only uses the shorthand version and does not allow us to write the full explicit version. enum Foo { case a(b: Int, c: Int) } switch Foo.a(b: 42, c: