Re: [swift-evolution] Add something like [unowned self] syntax for passing instance methods into closure parameters without creating retain cycles

> On Sep 13, 2016, at 22:34 , Xiaodi Wu via swift-evolution > wrote: > > It's similar to Linus' argument against using kernel debuggers > (https://lwn.net/2000/0914/a/lt-debugger.php3). Understanding your code at a > level above the source, and being careful, make

Re: [swift-evolution] Add something like [unowned self] syntax for passing instance methods into closure parameters without creating retain cycles

On Tue, Sep 13, 2016 at 10:29 PM, Karl Wagner via swift-evolution < swift-evolution@swift.org> wrote: > > Honestly, I’d be fine with / prefer only allowing unowned (at all) if > it’s @noescape, if that, requiring strong or weak for anything that > escapes. That seems to go along with swift’s

Re: [swift-evolution] Add something like [unowned self] syntax for passing instance methods into closure parameters without creating retain cycles

> Honestly, I’d be fine with / prefer only allowing unowned (at all) if it’s > @noescape, if that, requiring strong or weak for anything that escapes. That > seems to go along with swift’s emphasis on safety.  What?!?!! That's an extraordinary thing to say. I don't think you understand what

[swift-evolution] Swift 3.0 released!

Hi everyone, Swift 3.0 has been officially released: https://swift.org/blog/swift-3-0-released/ This moment marks an incredible achievement for the Swift open source community. The release is the culmination of an incredible amount of discussion and implementation work to bring it all

Re: [swift-evolution] Equatable auto-write func == Proposal

> On Sep 13, 2016, at 2:11 PM, Mark Sands via swift-evolution > wrote: > > I'm very interested in this moving forward. Is the swift team still holding > off on reviewing additive changes? Yep, we’re still focused on finishing Swift 3 and moving on to Swift 4 stage

Re: [swift-evolution] Equatable auto-write func == Proposal

I'm very interested in this moving forward. Is the swift team still holding off on reviewing additive changes? On Mon, Sep 12, 2016 at 10:43 AM, Tony Allevato via swift-evolution < swift-evolution@swift.org> wrote: > I started on an early-draft proposal for something like this a while back: >

Re: [swift-evolution] [swift-evolution-announce] [Accepted] SE-0140: Bridge Optional As Its Payload Or NSNull

> Le 13 sept. 2016 à 01:48, Greg Parker via swift-evolution > a écrit : > > >> On Sep 12, 2016, at 3:39 PM, Douglas Gregor > > wrote: >> >> As an amendment to SE-0140, Swift will produce a warning when an optional >>

Re: [swift-evolution] Add something like [unowned self] syntax for passing instance methods into closure parameters without creating retain cycles

> On Sep 13, 2016, at 10:29 AM, Benjamin Spratling via swift-evolution > wrote: > > Well, then also add an unowned convenience. > But I’ve never been handed a story from UX that said, “As a user, when I > want the app to crash.” > Using weak, the compiler can

Re: [swift-evolution] Add something like [unowned self] syntax for passing instance methods into closure parameters without creating retain cycles

Well, then also add an unowned convenience. But I’ve never been handed a story from UX that said, “As a user, when I want the app to crash.” Using weak, the compiler can tell me when I’ve missed a possible case where it’s nil. But the point here is to get closure references that don’t

Re: [swift-evolution] Add something like [unowned self] syntax for passing instance methods into closure parameters without creating retain cycles

Weak references can have a non-trivial amount of overhead in high-performance code. In some cases you can guarantee that a pointer should never be null - and that if it is, a serious logic error has occcurred and you *should* crash. I prefer crashing to running in an inconsistent

Re: [swift-evolution] Add something like [unowned self] syntax for passing instance methods into closure parameters without creating retain cycles

Nick, I like where you’re headed with the instance-methods-as-closures idea. Here’s where I’m headed with it: Closures are too often used to write the contents of what should be another function, producing code similar to the “pyramid of doom” avoided by guard. I now generally write as