[swift-evolution] What about garbage collection?

[Frank Ecsedy]

In fact, Java is looking to introduce value types and will have to wrestle
with how to do it in a pure GC environment. For Swift a GC is lots of pain
for minimal gain or even a net loss.

On Monday, February 8, 2016, Dave Abrahams via swift-evolution <
swift-evolution at swift.org> wrote:

>
> on Mon Feb 08 2016, Félix Cloutier <swift-evolution at swift.org
> <javascript:;>> wrote:
>
> > Has there been a garbage collection thread so far? I understand that
> > reference counting vs. garbage collection can be a heated debate, but
> > it might be relevant to have it.
> >
> > It seems to me that the two principal upsides of reference counting
> > are that destruction is (essentially) deterministic and performance is
> > more easily predicted. However, it comes with many downsides:
> >
> > object references are expensive to update
> > object references cannot be atomically updated
> > heap fragmentation
> > the closure capture syntax uses up an unreasonable amount of mindshare
> > just because of [weak self]
> >
> > Since Swift doesn't expose memory management operations outside of
> > `autoreleasepool`, it seems to me that you could just drop in a
> > garbage collector instead of reference counting and it would work (for
> > most purposes).
> >
> > Has a GC been considered at all?
>
> Yes.  Among other problems, you can't do copy-on-write efficiently with
> a GC, because you can't detect a unique reference.  And without
> efficient copy-on-write, most interesting value types (Array) are out
> the window.
>
> --
> -Dave
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <javascript:;>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160208/3a4135c5/attachment.html>