[swift-evolution] Add code to super methods.

Hallo, I have a very simple suggestion. And I’m not very sure then it haven’t been discussed already, so I’m sorry if that is the case. I would like to see the ability to just add code to base methods instead of overriding it and calling supers method. So basically an extension for methods.

Re: [swift-evolution] Add code to super methods.

At first glance I though about this: // Module A open class X { open func b() {} } // Module B class Y : X { addinto func b() { explodeExploit() } } class Z : X {} Z().b() // does this also call my `explodeExploit` :D ? Are you speaking of code injection of a sugar

Re: [swift-evolution] Add code to super methods.

Hi Mustafa, This is an interesting idea. The wording needs to be clear that it is not adding/injecting any code into the super-class. I would call it something like a cascading or chained method - there may be a better name and probably already is, because deinit already behaves in a similar way

Re: [swift-evolution] [pitch] Make exceptions visible in guard's else block

+1 for the idea of extending guard to allow catches (which still have to exit scope) before the else statement: guard let x = try foo() catch MyError.errorType { //Handle error & exit scope } catch MyError.otherErrorType { //Handle error & exit scope } else { //x was nil

Re: [swift-evolution] Add code to super methods.

All that said, there is a slight flaw here which is - what happens if you want to alter the input to super’s method in your override? That might be a deal-breaker. l8r Sean > On Nov 16, 2016, at 4:37 PM, Sean Heber wrote: > > That could be kind of neat - perhaps a syntax

Re: [swift-evolution] Add code to super methods.

Mustafa Sabur Yes I was talking about the override(before/after) like Sean. I don’t think it would make sense to actually extend some method, since the caller might not know that it happend. I can see some problems now and im going to try to find the old discussions. Thank you. Mustafa

Re: [swift-evolution] [pitch] Make exceptions visible in guard's else block

> On 16 Nov 2016, at 11:06, Nick Keets via swift-evolution > wrote: > > Hello all, I'm interested in a pattern to return failure, together with an > error > to explain why. I think that the "guard let x = x" discussion touched on the > issue, > but didn't really go

[swift-evolution] [pitch] Make exceptions visible in guard's else block

Hello all, I'm interested in a pattern to return failure, together with an error to explain why. I think that the "guard let x = x" discussion touched on the issue, but didn't really go in that direction. Right now, optional and boolean results work nicely with guards, but you only get

Re: [swift-evolution] Symmetrical operators

> On 14 Nov 2016, at 12:48, Haravikk via swift-evolution > wrote: > > I'm a +1 on the feature, though for simply handling symmetry it's not a super > critical issue. > > > I wonder though, when you start looking at symmetry is it worth looking at > other

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

> On 16 Nov 2016, at 05:25, Shawn Erickson wrote: > > Again my point isn't worrying about point of calling out to the delegate but > configuring my delegator to avoid a body of work or state management that is > unneeded if the delegate doesn't care about some mix of

Re: [swift-evolution] Symmetrical operators

> On Nov 16, 2016, at 9:25 AM, Karl via swift-evolution > wrote: > > >> On 14 Nov 2016, at 12:48, Haravikk via swift-evolution >> wrote: >> >> I'm a +1 on the feature, though for simply handling symmetry it's not a >> super critical

Re: [swift-evolution] Symmetrical operators

> On Nov 16, 2016, at 10:35, Stephen Canon wrote: > > >>> On Nov 16, 2016, at 10:47 AM, David Sweeris via swift-evolution >>> wrote: >>> >>> On Nov 16, 2016, at 9:25 AM, Karl via swift-evolution wrote:

Re: [swift-evolution] Contiguous Memory and the Effect of Borrowing on Safety

> On Nov 12, 2016, at 4:19 PM, David Sweeris via swift-evolution > wrote: > > >> On Nov 10, 2016, at 12:39 PM, Stephen Canon via swift-evolution >> wrote: >> >>> On Nov 10, 2016, at 1:30 PM, Dave Abrahams via swift-evolution >>>

Re: [swift-evolution] Symmetrical operators

> On Nov 16, 2016, at 10:47 AM, David Sweeris via swift-evolution > > wrote: > >> >> On Nov 16, 2016, at 9:25 AM, Karl via swift-evolution >> > wrote: >> >> >>> On 14

Re: [swift-evolution] Swift Extensions on Overlay Structs

> On Nov 13, 2016, at 11:43 PM, Fabian Ehrentraud via swift-evolution > wrote: > > That's an interesting idea without having to write type signatures twice. > > The different nullability of the absoluteURL is strange indeed - what if I do > a guaranteed cast from

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

> On Nov 16, 2016, at 3:52 PM, Karl via swift-evolution > wrote: > > >> On 16 Nov 2016, at 05:25, Shawn Erickson > > wrote: >> >> Again my point isn't worrying about point of calling out to the delegate but >>