pub type CFMutableDictionaryRef = *const __CFDictionary;

[jrmuizel]

Should this be *mut __CFDictionary?

[jrmuizel]

Also we have impl TCFTypeRef for *const T but not for *mut T. I ran into this when trying to update security-framework to a new version of core-foundation.

[faern]

@jrmuizel All ref types are *const. I just changed the remaining *mut __CFError into *const to have all of them the same.

Why do you need/want some of them to be *mut? EDIT: What error did you run into?

[faern]

Yes, TCFTypeRef is only implemented for *const T on purpose. Since it converts to and from *const c_void.

[jrmuizel]

Why *const? Since we're going to be mutating at least the refcount and sometimes the whole object pointed to by the ref type shouldn't they be *mut?

[faern]

@jrmuizel Every ref raw pointer definition in the crate, except for CFError, was already *const. And it seemed to have worked fine, since no one had reported an issue. So I thought changing one instead of changing all the others was both easier and probably more correct.

We never mutate any data behind the pointers inside this crate, or in Rust at all. We just pass the pointers to CFRetain and CFRelease for example and they don't care if the pointer is mutable or not.

[faern]

These C functions actually want *const pointers in our FFI bindings to them: https://docs.rs/core-foundation-sys/0.5.0/core_foundation_sys/base/fn.CFRelease.html

[faern]

@jrmuizel What practical problem does it cause to have *const? What problem did you run into in security-framework?

[jrmuizel]

All of the ref types here are mut. Do we have a justification for changing them to *const?

[faern]

I'm not sure. Because all of core-foundation use const and the ffi functions take const pointers, that's the only reason I can come up with. Maybe this crate should have everything *mut. I don't think it matters very much as long as everyone do the same. Maybe the person who started using *const all over this crate has a reason? :)

[faern]

Iff we come to the conclusion that it does not matter; then I would argue that the reason to change in security-framework is because this crate has had *const for most types for quite a while, it's already made consistent and is ready for release. While on the other hand, security-framework will need a lot of updating anyway so changing to *const could just be done at the same time.

[jrmuizel]

@sfackler would you object to changing security-framework to use *const for it's ref types instead of *mut?

[Gankra]

(asked on IRC to toss in my two cents here)

There's no language-level significance between *mut and *const that should matter here (*const is covariant, but that shouldn't matter); they're basically intended as lints/hints for correct usage. In that regard *mut is more "correct" here as it's honest about the mutations that will be performed.

That said, I personally don't think this hint is important enough to refactor your whole codebase over, but I believe sfackler cares about it more strongly.

[sfackler]

I like to match the C type definitions exactly, even when they're not const-correct.

I'm going to do a big breaking release for security-framework soon so if there are changes needed on the securyt-framework side that's fine.

[jdm]

#152