<div dir="ltr">Interesting, I'm not familiar with the history of the feature in Rust. Are you able to provide more details on what went wrong in practice?<div><div><br></div><div>This proposal may be different, this is not attempting to do it without GC. What I'm suggesting still uses ARC (assuming you were counting ARC as GC). It does provide the compiler many opportunities to optimise ARC though.</div><div><br></div><div>I really like what Rust ended up with, but I'm concerned that it's very complicated, and I want to explore alternatives. From <a href="https://doc.rust-lang.org/book/ownership.html">https://doc.rust-lang.org/book/ownership.html</a>:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">However, this system does have a certain cost: learning curve. Many new users to Rust experience something we like to call ‘fighting with the borrow checker’.</blockquote><div><br></div><div> </div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 30, 2016 at 1:22 PM, Joe Groff via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Rust attempted this sort of type-directed cycle prevention early in its development, when it was attempting to provide language-supported shared references without GC, and it didn't work out well for them in practice.<br>
<br>
-Joe<br>
<br>
> On Jul 29, 2016, at 6:42 PM, Andrew Bennett via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> I'd like an opt-in way to verify and prevent unintentional strong references in Swift.<br>
><br>
> This can be used to verify ownership structures, and ultimately avoid retain cycles.<br>
><br>
> Read a draft proposal here:<br>
> <a href="https://github.com/therealbnut/swift-evolution/blob/therealbnut-explicit-ownership/proposals/NNNN-explicit-ownership-type-attribute.md" rel="noreferrer" target="_blank">https://github.com/therealbnut/swift-evolution/blob/therealbnut-explicit-ownership/proposals/NNNN-explicit-ownership-type-attribute.md</a><br>
><br>
> TL;DR:<br>
><br>
> If you have any questions please read the proposal before asking here.<br>
><br>
> It's an opt-in attribute that defines a whitelist of types something can own. For example:<br>
><br>
> @owns(TypeA, TypeB) struct TypeC { ... }<br>
><br>
> I wrote this a few months ago, but we weren't accepting additive proposals. Now we're explicitly looking for something like this:<br>
><br>
> Memory ownership model: Adding an (opt-in) Cyclone/Rust inspired memory ownership model to Swift is highly desired by systems programmers and folks who want predictable and deterministic performance (for example, in real time audio processing code). More pertinent to the goals of Swift 4, this feature is important because it fundamentally shapes the ABI. It informs code generation for “inout", how low-level “addressors” work in the ABI, impacts the Swift runtime, and will have a significant impact on the type system and name mangling.<br>
><br>
> - Chris<br>
><br>
> ----<br>
><br>
> Here's a link to the version of the proposal when I sent this email.<br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>