<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Apr 11, 2016 at 12:04 PM Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Yes, that's exactly the goal. One follow-up question: I'm not so much concerned about there existing some runtime, but rather what is in it. In particular, threads, memory management that is hard to integrate with other programs, or something else that you might think an impediment to embedding in other programs that have concurrency or memory models.<br>
<br>
Swift's runtime consists mostly of the runtime database for generic type metadata and associated casting/querying logic, and support for reference counting and allocation of Swift classes and other heap objects. The type database takes up memory, but is all lazily initialized and concurrency-safe so should be mostly invisible to external code. Interfacing Swift reference counting with other memory management systems has many of the same challenges as would other reference counting schemes, such as ObjC, COM, or GObject, but should be straightforward compared to, say, a GC system where pinning objects is necessary while they're accessible from C.<br></blockquote><div><br></div><div>That's wonderful. Okay, I'll play with this. Thanks. </div></div></div>