[swift-dev] Disallowing weak struct properties

Paul Cantrell cantrell at pobox.com
Fri Jan 29 20:37:59 CST 2016


> On Jan 29, 2016, at 7: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.
> 
> … 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. …

Well, this would certainly pour some cold water on Siesta. It might be able to get by with what you describe, but it’s hard to say without a more specific proposal on the weak-supporting collections. (Without such collections, this would be something of a disaster for the library.)

On the one hand, almost all the weak properties in the whole project occur in structs.

On the other hand, those structs are all meant to support weak collections of various kinds.

On the other other hand, the behavior is more complex than what you outlined above:

there’s StrongOrWeakRef struct used by a cache that needs to be able to switch specific references from strong to weak (at which point auto-compaction of the weak ones would be desirable), and
a WeakRef that hangs on to referent’s ObjectIdentifier’s hash and identity, so that it can be a stable dictionary key.

The second I imagine a dictionary with first-class support for weak keys would probably cover. The first seems pretty purpose-specific, however, and it’s less clear that general-purpose weak collections would cover it.

The StrongOrWeakRef usage suggests, I think, that weak collections may not quite be one size fits all, and having the ability to wrap a weak ref in a struct without incurring an additional allocation may be worth the trouble. At the very least, they’d need some serious thought.

You can see the relevant bits of the code in question here:

https://github.com/bustoutsolutions/siesta/blob/e29a5967e7c7e223377107ff2bdc53180f0d2951/Source/Support/ARC%2BSiesta.swift

Cheers,

Paul

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160129/b6b05a8d/attachment.html>


More information about the swift-dev mailing list