<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Your WeakBox-backed property is more or less how I imagine the <i class="">semantics</i> of a weak var in a struct — but in the Siesta example elsewhere on this thread, the allocation overhead if it were actually <i class="">implemented</i> this way would be pretty painful.</div><div class=""><br class=""></div><div class="">P</div><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 29, 2016, at 9:33 PM, Jordan Rose via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">The workaround would be boxing the weak reference in a final class, which isn't particularly efficient (or small!) but would be equivalent.</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">private final class WeakBox<T: AnyObject> {</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""> weak var ref: T?</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""> init(ref: T?) { self.ref = ref }</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">}</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><br class=""></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">class Foo { … }</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><br class=""></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">struct FooUser {</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""> private var box: WeakBox<Foo></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""> init(ref: Foo?) { self.box = WeakBox(ref) }</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""> var ref: Foo? {</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""> get { return box.ref }</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""> set {</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""> // Don't mutate the existing box, which may be shared with other FooUser instances</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""> box = WeakBox(newValue)</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""> }</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""> }</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">}</blockquote><div class=""><br class=""></div><div class="">We could also just make this the implementation of weak-in-structs (possibly with coalescing of multiple weak variables, possibly not), which would get us the optimization properties even if it doesn't fix what I see as a semantic hole. To me, though, weak properties in structs are semantically <i class="">wrong</i> because they're never actually constant. (Unowned ones, on the other hand, are just checked non-owning references, which means they don't mutate if your program is correct.)</div><div class=""><br class=""></div><div class="">Jordan</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 29, 2016, at 19:24 , David Sweeris <<a href="mailto:davesweeris@mac.com" class="">davesweeris@mac.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">I'm against it, unless structs can have "WeakCollectionType" properties (which seems like it'd necessarily involve some of that compiler magic we're trying to avoid).<br class=""><br class="">If reference/value semantics weren't tied to struct/class, I'd care a lot less.</div><div class=""><br class=""></div><div class="">I also wouldn't object to removing them from structs, but then adding a "strass" object classification for when you need weak inside a value-semantics object.<br class=""><br class="">-Dave Sweeris<br class=""><br class="">Sent from my iPhone</div><div class=""><br class="">On Jan 29, 2016, at 17:56, Jordan Rose via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class="">Hi, everyone. What do you think about dropping support for 'weak' in struct properties? This would fix a semantic issue—'let' structs containing weak properties won't change out from under you—and (AFAICT) would make all values trivially movable, which is a great quality to have.<br class=""><div class=""><br class=""></div><div class="">This wouldn't change local variables, top-level variables, or class properties, just structs. It <i class="">would</i> make having an array of weak references a little harder, but honestly we should have proper weak-supporting collections anyway; as I understand it the behavior you usually want is auto-compacting rather than leaving a hole. (Evidence: Cocoa has NSHashTable for weak sets and NSMapTable for dictionaries with weak keys and/or values; there's no variant of NSArray that supports weak references other than by making a custom CFArray and being very very careful how you access it.)</div><div class=""><br class=""></div><div class="">Anyway, thoughts? It's not really my department but it cleans up the same areas that are being affected by struct resilience.</div><div class="">Jordan</div><div class=""><br class=""></div><div class="">P.S. I know this would have to go through swift-evolution for real. I just want to know if it's a silly idea to begin with.</div></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-dev mailing list</span><br class=""><span class=""><a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-dev" class="">https://lists.swift.org/mailman/listinfo/swift-dev</a></span><br class=""></div></blockquote></div></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-dev mailing list<br class=""><a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-dev<br class=""></div></blockquote></div><br class=""></body></html>