[swift-evolution] What about garbage collection?

davesweeris at mac.com davesweeris at mac.com
Wed Feb 10 10:46:13 CST 2016

> On Feb 10, 2016, at 00:57, Jean-Denis Muys via swift-evolution <swift-evolution at swift.org> wrote:
> Based on this as the summary of arguments I read so far on this thread, I tend to increase my +1. Here is what I read:
> - arguments regarding energy efficiency, memory efficiency, or more generally hardware limitations seem to me rather short-sighted, as in “640 KB or RAM should be enough for all times to come” (original design decision by IBM for the PC). Is Swift a language designed for todays hardware? Or is it supposed to outlast it a wee bit?
Planning for the future is a Good Thing, but if Swift isn’t useful today, it won’t last long enough for “the future” to get here. There are limitations in the current hardware (VM thrashing the NAND in iDevices, IIRC) that preclude other options.

> Of course some ideal would be a language where GC is an option. I am not sure whether that is possible, though the one argument I saw against that, namely that libraries would be compatible with one of the options only, can be solved with the fat binary idea. We used to have libraries compatible with both PowerPC and Intel processors. That sounds a lot more complex.

We did it once before… Obj-C switched from manual memory management to ARC back in Xcode 4.2. Personally, I’d *much* rather stick with ARC for now, and worry about switching to some other scheme a few years down the road when supporting devices with write limitations starts becoming less of an issue.

- Dave Sweeris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160210/47e30717/attachment.html>

More information about the swift-evolution mailing list