<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 29, 2016, at 5:56 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="">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></div></blockquote><div><br class=""></div><div>I brought this up internally last year, and we decided to keep the current behavior. Weak references are atomically managed by the compiler and runtime, so code should always see all copies of a weak reference in immutable values go to nil simultaneously. You effectively get the semantics of a weak var stored in a box, but without the box. In resilient cases, I don't think we want to make assumptions that opaque types are trivially movable irrespective of weak references, since that would severely limit our future ability to interop with C++ value types in the future, so I don't see any benefit to introducing this constraint.</div><div><br class=""></div><div>-Joe</div></div></body></html>