[swift-dev] Disallowing weak struct properties

[John McCall]

> On Jan 29, 2016, at 6:31 PM, Jordan Rose <jordan_rose at apple.com> wrote:
>> On Jan 29, 2016, at 18:22 , John McCall <rjmccall at apple.com> wrote:
>> 
>>> 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
>> 
>> Is there a formalizable notion of “change” here that doesn’t include changes in mutable referents and that isn’t just restating bit-equivalence?
> 
> If you treat the "value" of a reference as its referent's identity rather than contents, then the "value" of a struct is fully captured by the "values" of its members (which happens to be bitwise equality). The struct value has no identity.

This is true of weak references as well: the value is the same independent of where it is stored.  However, the value *is* dependent on global state.

> The particular benefit we'd get here is that existential boxes could be passed in registers, but Slava pointed out that we could just force values containing weak references to be stored out of line even if they'd otherwise fit in the box.

Yes.

>>> —and (AFAICT) would make all values trivially movable, which is a great quality to have.
>> 
>> If you sweep “unowned" up with “weak”, yes, this is true of the current language.  It’s not an obvious restriction that we want to adopt forever, though.
> 
> I thought unowned was ref-counted (and therefore forwardable) as well, or are we dropping that implementation because we couldn't get it to work with objc?

Unowned references to pure-Swift classes are ref-counted.  Unowned references to unrestricted classes have to be (well, “have to be”) address-only for ObjC interop reasons; I fixed that sometime in December.

John.