[swift-dev] Disallowing weak struct properties

Joe Groff jgroff at apple.com
Sat Jan 30 12:07:25 CST 2016


> On Jan 29, 2016, at 5:56 PM, Jordan Rose via swift-dev <swift-dev at swift.org> wrote:
> 
> 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.
> 
> This wouldn't change local variables, top-level variables, or class properties, just structs. It would 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.)
> 
> Anyway, thoughts? It's not really my department but it cleans up the same areas that are being affected by struct resilience.

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.

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160130/8414fcd4/attachment.html>


More information about the swift-dev mailing list