Bryan Jones

@nirinchev Thinking more on this, I *really* recommend that you guys reconsider at least one part. Users are going to do this: ``` someMap["someKey"] = nil ``` In Swift dictionaries,...

@tgoyne yep! The status quo for `someMap["someKey"] = nil` is correct. There was some talk of changing that above, but the `.none` case (documentation anyone?) solves the issue of how...

@Jaycyn the proposed behavior is to leave the key in place and the value becomes nil. I personally think that's a bad call because it makes the collection leaky--no other...

@Jaycyn In my opinion, the default behavior should be that when an Object value is deleted from the Realm, both Key and Value are removed from a Map. If it...

Just to make sure this horse is *really* dead: another irritating side-effect of `Map`'s insistence on keeping keys is this: ``` let values: Results = someMap.where({ $0.someCondition == true })...

@nirinchev I think this one has been handled with a fix on Atlas. The determination was that `map` is allowed to contain nil values (unlike all other Realm collections) because...

I’m not too worried. The argument that the keys should remain because they have important meaning is flawed. Consider a `List`: it may be semantically important that an object is...

It’s really pretty simple: all collections in Realm are self-cleaning EXCEPT `map`. Map will accrue cruft as objects are deleted. It requires very special handling. That fact is not documented...

Map’s behavior is ALSO inconsistent with how Swift dictionaries behave. If you nuke a value in a Swift dictionary, the key gets removed as well. Everything about this design runs...

@Jaycyn Sure, I see that approach. But there are two complications: 1) The LinkingObjects keyPaths *DO* work when they're specified as Strings rather than PartialKeyPaths. This implies that Realm *can*...