You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Being the main struct internally an Arc<Inner>, when the user clones it's simply getting a new smart pointer to the same underlying data, that would be unexpected if paragoned to std HashMap.
Plus, in some examples, ShardMap is wrapped in an Arc, making it a double level of indirection without gainin nothing.
I think in Rust philosophy Arc should be user's duty and not hardcoded inside the struct.
The text was updated successfully, but these errors were encountered:
I've gone back and forth a few times about this - I totally agree that leaving Arc-ing something up to the API consumer, but I also want to allow holding strong references into a specific shard for a 'static lifetime at some point, which would require an Arc'd map.
Right now, I'm thinking of implementing some methods specifically for self: Arc<Self> so that I can allow holding strong references if the type is wrapped in an Arc but still leave that up to the user. Thoughts?
Being the main struct internally an
Arc<Inner>
, when the user clones it's simply getting a new smart pointer to the same underlying data, that would be unexpected if paragoned to std HashMap.Plus, in some examples, ShardMap is wrapped in an Arc, making it a double level of indirection without gainin nothing.
I think in Rust philosophy Arc should be user's duty and not hardcoded inside the struct.
The text was updated successfully, but these errors were encountered: