[swift-dev] Disallowing weak struct properties

[Paul Cantrell]

Your WeakBox-backed property is more or less how I imagine the semantics of a weak var in a struct — but in the Siesta example elsewhere on this thread, the allocation overhead if it were actually implemented this way would be pretty painful.

P

> On Jan 29, 2016, at 9:33 PM, Jordan Rose via swift-dev <swift-dev at swift.org> wrote:
> 
> 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 <mailto: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>
> 
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> 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/903f1a15/attachment.html>