Converting between dictionary types

[faern]

I'm trying to use the CFDictionary and CFMutableDictionary types more extensively. But run into problems. They are not very compatible with each other. This crate for example does not expose any clean way of using CFDictionaryCreateMutableCopy to create a CFMutableDictionary from any CFDictionary. I added a From implementation for this.

It was not possible to, in some safe/simple way, cast a CFDictionary<K, V> into the untyped CFDictionary<*const c_void, *const c_void> something I added to_untyped to be able to do.

When it comes to downcasting, it was not possible to downcast a CFType into a dictionary, since they don't implement ConcreteCFType. Something they probably should, for the case where the keys and values are just void pointers. CFArray does exactly this.

Lastly, what I needed the most was to be able to convert a CFMutableDictionary into a CFDictionary. This allows me to borrow an immutable CFDictionary via the ItemRef type basically. It's possible to work around this and actually have owned instances of a CFDictionary and a CFMutableDictionary pointing to the same actual dictionary by doing this:

let mut_dict = CFMutableDictionary::new();
let mut_dict2 = mut_dict.clone();
let dict = mut_dict.as_immutable();
// Here one can mutate the dict via `mut_dict2` while `dict` is still in scope/alive.

But since we already allow cloning a CFMutableDictionary to have two mutable references to the same dictionary I guess someone decided this should be viewed as safe. Both CFDictionary and CFMutableDictionary does not implement Send so we should not end up in any actual thread inconsistencies here.

If the above is indeed considered safe, I could get rid of the ItemRef juggling and just make it fn as_immutable(&self) -> CFDictionary directly maybe? Would simplify usage.

---

This change is 

[faern]

I'm not completely sure this is correct or safe, but I think it is. The docs say that a mutable dictionary can be viewed as an immutable one, from my understanding. But not the other way around. So looking at a mutable dictionary as a propertylist should just be an extension of viewing it as an immutable dictionary then?

[faern]

As I wrote in the initial description above, trying to limit this usage so the mutable dictionary acts as borrowed (thus immutable) while the returned value exists might be overkill/false claims. Since it's so easy to go around it anyway. Anyone can just clone their mutable dictionary and make one of them immutable and still have a mutable version.

With the added addition of

 impl<K, V> CFPropertyListSubClass for ::dictionary::CFMutableDictionary<K, V> {} 

below (Which we have not yet debated if it's correct or not), they could also just do

let mut_dict = CFMutableDictionary::new();
let dict = mut_dict.to_CFPropertyList().downcast::<CFDictionary>().unwrap();

and that way also have an owned immutable dictionary be live at the same time as a mutable version pointing to the same underlying dictionary.

[faern]

Since it was so easy to work around the borrowing here anyway I decided to revert that in the last commit. If we allow cloning of CFMutableDictionary I don't see why we would not allow this.

[faern]

I reverted the commit where I implemented CFPropertyListSubClass for CFMutableDictionary. I also removed the ConcreteCFType implementation for CFMutableDictionary. I realized these traits are not only for casting up to the more generic parent type, they are also for downcasting from them to the given subclass. Since mutable dictionaries have the same type ID as their immutable counterparts, it became possible to cast any CFType or CFPropertyList that was of CFDictionary type down to a CFMutableDictionary and then modify it, thus causing a segfault without any unsafe code.

[faern]

How stupid of me.. This of course applies to for example impl<T> CFPropertyListSubClass for ::array::CFArray<T> {} as well. That would allow downcasting to a typed array directly, which would not be safe. I removed the generics on these CFPropertyListSubClass implementations again..

[jdm]

I agree with your reasoning on all points. I don't think it makes sense to try to enforce Rust's views of immutable/mutable when binding to APIs that can work around it easily.

[jdm]

@bors-servo r+

[bors-servo]

📌 Commit 1cb7f08 has been approved by jdm

[bors-servo]

⌛ Testing commit 1cb7f08 with merge b937267...

[bors-servo]

☀️ Test successful - status-travis
Approved by: jdm
Pushing b937267 to master...