[swift-evolution] What about garbage collection?
david at alkaline-solutions.com
Tue Feb 9 11:01:52 CST 2016
When programming C and C++, I had a strong requirement that my testing tools were clean, so that I could run tools similar to leaks over my unit/integration test suite.
> On Feb 9, 2016, at 5:16 AM, Michel Fortin via swift-evolution <swift-evolution at swift.org> wrote:
> 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
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4139 bytes
Desc: not available
More information about the swift-evolution