[swift-evolution] What about garbage collection?

Michel Fortin michel.fortin at michelf.ca
Tue Feb 9 06:16:47 CST 2016

Le 8 févr. 2016 à 23:34, Charles Srstka <cocoadev at charlessoft.com> a écrit :
>> On Feb 8, 2016, at 10:20 PM, Michel Fortin via swift-evolution <swift-evolution at swift.org> wrote:
>> Le 8 févr. 2016 à 16:00, Chris Lattner via swift-evolution <swift-evolution at swift.org> a écrit :
>>> I’m personally not interested in requiring a model that requires us to throw away a ton of perfectly good RAM to get an “simpler" programming model - particularly on that adds so many tradeoffs.
>> Me neither. I certainly prefer ARC. Hence one reason I like Swift more than D.
>> I'd just like to point out that a "fake" GC that stops short of actually freeing objects to instead print a warning on the console listing objects to be collected would be a great help to detect and fix cycles early in development.
> Isn’t this essentially what the ‘leaks’ tool is?

I think so. Except you rarely use the `leaks` tool early in development. If this was baked into debug builds (with a way to opt out, of course), retain cycles would be caught much earlier in the development process and you'd see your leaks almost immediately after writing the offending code.

In fact, I'm pretty sure most people here don't check for leaks even in the final build of their app unless there's an obvious leakage problem. I know I don't, generally.

Michel Fortin

More information about the swift-evolution mailing list