[swift-dev] Disallowing weak struct properties

Jordan Rose jordan_rose at apple.com
Fri Jan 29 21:33:09 CST 2016


The workaround would be boxing the weak reference in a final class, which isn't particularly efficient (or small!) but would be equivalent.

private final class WeakBox<T: AnyObject> {
  weak var ref: T?
  init(ref: T?) { self.ref = ref }
}

class Foo { … }

struct FooUser {
  private var box: WeakBox<Foo>
  init(ref: Foo?) { self.box = WeakBox(ref) }
  var ref: Foo? {
    get { return box.ref }
    set {
      // Don't mutate the existing box, which may be shared with other FooUser instances
      box = WeakBox(newValue)
    }
  }
}

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 wrong 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.)

Jordan

> On Jan 29, 2016, at 19:24 , David Sweeris <davesweeris at mac.com> wrote:
> 
> 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).
> 
> If reference/value semantics weren't tied to struct/class, I'd care a lot less.
> 
> 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.
> 
> -Dave Sweeris
> 
> Sent from my iPhone
> 
> On Jan 29, 2016, at 17:56, Jordan Rose via swift-dev <swift-dev at swift.org <mailto: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.
>> Jordan
>> 
>> 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.
>> _______________________________________________
>> swift-dev mailing list
>> swift-dev at swift.org <mailto:swift-dev at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>

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


More information about the swift-dev mailing list