Re: [swift-users] Checking whether an object is uniquely referenced, using a weak reference to it

[Dave Abrahams via swift-users]

on Tue Jun 28 2016, Jordan Rose  wrote:

>> On Jun 27, 2016, at 18:52, Tim Vermeulen  wrote:
>> 
>> Thanks for your reply. It didn’t clear up everything, though. The
>> official documentation says "Weak references do not affect the
>> result of this function.”, which suggests that weak (and unowned)
>> references intentionally aren’t counted. The docs only mention the
>> implementation of copy-on-write behaviour as a use case (which also
>> happens to be what I’m using it for).
>
> I would expect that weak references are important to count for COW,
> since you can observe changes through them. Dave?

This sort of depends on what you expect the semantics of your weak
reference to be.  It's not possible to take a weak reference to an
Array; you can only take a weak reference to the NSArray it uses as a
backing store.  That's an Objective-C-only idea.

Given an arbitrary NSArray on the Objective-C side, it might turn out to
be an NSMutableArray, so if you want to avoid observing changes to it,
in principle you need to copy it.  So I think it's possible to argue
that the weak reference count is not an issue here.

-- 
-Dave
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Checking whether an object is uniquely referenced, using a weak reference to it

[Joe Groff via swift-users]

> On Jun 28, 2016, at 9:32 AM, Jordan Rose via swift-users 
>  wrote:
> 
> 
>> On Jun 27, 2016, at 18:52, Tim Vermeulen  wrote:
>> 
>> Thanks for your reply. It didn’t clear up everything, though. The official 
>> documentation says "Weak references do not affect the result of this 
>> function.”, which suggests that weak (and unowned) references intentionally 
>> aren’t counted. The docs only mention the implementation of copy-on-write 
>> behaviour as a use case (which also happens to be what I’m using it for).
> 
> I would expect that weak references are important to count for COW, since you 
> can observe changes through them. Dave?

Passing a weak reference inout goes through a strong optional shadow copy. It 
wouldn't be safe to directly address the weak reference.

-Joe

>> 
>> Couldn’t there just a be a function that returns the reference count of a 
>> given object as an Int? It would make everything a lot easier (i.e. it 
>> wouldn’t need inout because it can just create a reference to that object, 
>> find the reference count, then subtract 1).
> 
> As we’ve said for a long time in Objective-C, asking for the reference count 
> of an object is meaningless. isUniquelyReferenced only works because it’s 
> conservative: because it only checks for “exactly 1”, it’s safe from 
> threading issues and autorelease pools. We do not plan to add a -retainCount 
> equivalent to Swift.
> 
> Jordan
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Checking whether an object is uniquely referenced, using a weak reference to it

[Tim Vermeulen via swift-users]

Thanks for your reply. It didn’t clear up everything, though. The official 
documentation says "Weak references do not affect the result of this 
function.”, which suggests that weak (and unowned) references intentionally 
aren’t counted. The docs only mention the implementation of copy-on-write 
behaviour as a use case (which also happens to be what I’m using it for).

Couldn’t there just a be a function that returns the reference count of a given 
object as an Int? It would make everything a lot easier (i.e. it wouldn’t need 
inout because it can just create a reference to that object, find the reference 
count, then subtract 1).

> Hi, Tim. The purpose of the isUniquelyReferenced checks is to see whether any 
> changes to the properties of the object can be observed from elsewhere in 
> this program. Therefore, I wouldexpectit to return ‘false’ when there are 
> weak (or unowned) references present, i.e. I think the bug is that we don’t 
> consider weak or unowned references to count for this check.
> 
> If my understanding of the intended behavior is correct, then it doesn’t make 
> sense to check for a uniquely-referenced object through a weak (or unowned) 
> reference, because if that were the only reference, then the object would 
> have already been deallocated.
> 
> The particular technical reason for the check failing is related to the 
> inout, as you say: in order to pass the reference to the function inout, it 
> has to be loaded into a strong reference first. The reason the inout is there 
> at all is because otherwise the check would fail: there would be a reference 
> from outside the function in addition to the one for the argument.
> 
> Hope that clears things up, and if you agree with my interpretation about 
> weak and unowned references, please file a bug 
> atbugs.swift.org(http://bugs.swift.org)!
> Jordan
> 
> 
> > On Jun 27, 2016, at 17:14, Tim Vermeulen via 
> > swift-userswrote:
> > classEmptyClass {}
> > 
> > varstrongReference =EmptyClass()
> > weakvarweakReference =strongReference
> > 
> > print(isUniquelyReferencedNonObjC())// true
> > print(isUniquelyReferencedNonObjC())// false
> > 
> > 
> > I expected both print statements to print true.
> > 
> > I realise that this is probably a known limitation of this function. After 
> > all, if it worked with weak references too, there’s no point for the 
> > parameter to be inout:
> > 
> > funcwrappedIsUniquelyReferencedNonObjC(_object:T) ->Bool{
> > weakvarweakObject = object
> > returnisUniquelyReferencedNonObjC()
> > }
> > 
> > 
> > So the fact that this function takes an inout parameter hints at the fact 
> > that it doesn’t work with weak references. If my reasoning is correct, it 
> > would be nice if the docs stated that it only works with strong references 
> > to objects. :)
> > 
> > My question is, is it possible at all to use a weak reference to check 
> > whether an object is uniquely referenced or not? Since this approach 
> > doesn’t seem to work, I guess it is 
> > impossible?___
> > swift-users mailing list
> > swift-users@swift.org(mailto:swift-users@swift.org)
> > https://lists.swift.org/mailman/listinfo/swift-users
> 
> 
> 
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Checking whether an object is uniquely referenced, using a weak reference to it

[Jordan Rose via swift-users]

Hi, Tim. The purpose of the isUniquelyReferenced checks is to see whether any 
changes to the properties of the object can be observed from elsewhere in this 
program. Therefore, I would expect it to return ‘false’ when there are weak (or 
unowned) references present, i.e. I think the bug is that we don’t consider 
weak or unowned references to count for this check.

If my understanding of the intended behavior is correct, then it doesn’t make 
sense to check for a uniquely-referenced object through a weak (or unowned) 
reference, because if that were the only reference, then the object would have 
already been deallocated.

The particular technical reason for the check failing is related to the inout, 
as you say: in order to pass the reference to the function inout, it has to be 
loaded into a strong reference first. The reason the inout is there at all is 
because otherwise the check would fail: there would be a reference from outside 
the function in addition to the one for the argument.

Hope that clears things up, and if you agree with my interpretation about weak 
and unowned references, please file a bug at bugs.swift.org 
!
Jordan


> On Jun 27, 2016, at 17:14, Tim Vermeulen via swift-users 
>  wrote:
> 
> class EmptyClass {}
> 
> var strongReference = EmptyClass()
> weak var weakReference = strongReference
> 
> print(isUniquelyReferencedNonObjC()) // true
> print(isUniquelyReferencedNonObjC())   // false
> 
> I expected both print statements to print true.
> 
> I realise that this is probably a known limitation of this function. After 
> all, if it worked with weak references too, there’s no point for the 
> parameter to be inout:
> 
> func wrappedIsUniquelyReferencedNonObjC(_ object: T) -> Bool {
> weak var weakObject = object
> return isUniquelyReferencedNonObjC()
> }
> 
> So the fact that this function takes an inout parameter hints at the fact 
> that it doesn’t work with weak references. If my reasoning is correct, it 
> would be nice if the docs stated that it only works with strong references to 
> objects. :)
> 
> My question is, is it possible at all to use a weak reference to check 
> whether an object is uniquely referenced or not? Since this approach doesn’t 
> seem to work, I guess it is impossible?
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] Checking whether an object is uniquely referenced, using a weak reference to it

[Tim Vermeulen via swift-users]

class EmptyClass {}

var strongReference = EmptyClass()
weak var weakReference = strongReference

print(isUniquelyReferencedNonObjC()) // true
print(isUniquelyReferencedNonObjC())   // false

I expected both print statements to print true.

I realise that this is probably a known limitation of this function. After all, 
if it worked with weak references too, there’s no point for the parameter to be 
inout:

func wrappedIsUniquelyReferencedNonObjC(_ object: T) -> Bool {
weak var weakObject = object
return isUniquelyReferencedNonObjC()
}

So the fact that this function takes an inout parameter hints at the fact that 
it doesn’t work with weak references. If my reasoning is correct, it would be 
nice if the docs stated that it only works with strong references to objects. :)

My question is, is it possible at all to use a weak reference to check whether 
an object is uniquely referenced or not? Since this approach doesn’t seem to 
work, I guess it is impossible?___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users