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

Weak-keyed/weak-valued hashed collections #2

Open
lorentey opened this issue Apr 5, 2021 · 0 comments
Open

Weak-keyed/weak-valued hashed collections #2

lorentey opened this issue Apr 5, 2021 · 0 comments
Labels
enhancement New feature or request

Comments

@lorentey
Copy link
Member

lorentey commented Apr 5, 2021

A weak Set and a weak-keyed (or weak-valued) Dictionary are often-requested data structures that aren't easy to implement. It's especially difficult to do it correctly in terms of the existing Set and Dictionary -- most attempts end up accidentally changing the identity of keys already in a hash table, which violates invariants and leads to runtime errors.

This package would be a good place to host a set of weak collection implementations.

While the implementation isn't entirely trivial, I expect this will be mostly an API design challenge. Some notes:

  • These would work best if they came with their own hash table implementation whose lookup etc. operations are aware of the fact that keys/values could disappear at any moment, and are able to update the table accordingly.
  • Deallocated keys work like tombstones.
  • The Element, Key and/or Value types would be constrained to AnyObject. We can probably still allow custom Hashable implementations, as long as the hash table operations are aware of niled out entries. The tradeoff here is that requiring Hashable will make developers do more work by having to manually implement it, even if they only want to use object identity.
  • Ideally lookup operations would be able to incrementally update the table by getting rid of obsolete entries they encounter. A mutating lookup would probably preclude the use of these types in concurrent contexts. This is fine -- these are typically used for caches local to a particular actor.
  • These types probably won't be able to conform to Collection as their count can change at any point. This is fine -- they shouldn't even provide a count of live entries.
  • The types may or may not implement value semantics (depending on whichever choice makes most sense). This is fine.
@lorentey lorentey added the enhancement New feature or request label Apr 5, 2021
CTMacUser pushed a commit to CTMacUser/swift-collections that referenced this issue Jul 1, 2021
Iterative instead of recursive implementation, @inline(__always) a few more functions
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant