Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-8538] runtime: isKnownUniquelyReferenced should return false if there's any weak/unowned refs (or offer new function with those semantics) #51057

Closed
weissi opened this issue Aug 15, 2018 · 1 comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. standard library Area: Standard library umbrella

Comments

@weissi
Copy link
Member

weissi commented Aug 15, 2018

Previous ID SR-8538
Radar None
Original Reporter @weissi
Type Bug
Status Resolved
Resolution Duplicate
Additional Detail from JIRA
Votes 0
Component/s Standard Library
Labels Bug
Assignee None
Priority Medium

md5: b5391a3e7ca4c1d0a2da45e0374809ca

duplicates:

  • SR-5633 isKnownUniquelyReferenced(_:) should optionally consider weak/unowned references

Issue Description:

At the moment, isKnownUniquelyReferenced returns true if there's exactly one strong reference, no matter how many weak/unowneds there are.
In most cases this is not a huge issue because it's mostly used to check if a value type need's to CoW it's storage class. The class is normally not publicly accessible so there's no way random bits of code could create a weak/unowned reference. On the flip-side however that's a great argument to make it only returns true if there's one strong and no weak/unowned refs whatsoever as it won't change any correct code.

Long story short: We should change isKnownUniquelyReferenced to return true only iff there's one strong and no weak/unowned references.

EDIT: After reading SR-5633, it turns out that the existing behaviour might be useful so maybe we should have a new runtime call which has the semantics I describe here.

@atrick
Copy link
Member

atrick commented Aug 15, 2018

@gparker42 says in SR-5633:

Perhaps we'll deprecate the current function and add new functions that are more explicit about which references they're checking.

That's a swell idea that would be an adequate fix for this bug.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. standard library Area: Standard library umbrella
Projects
None yet
Development

No branches or pull requests

2 participants