Encode is not implemented for *mut libc::c_void anymore

[SimonSapin]

dee2e48#diff-00e732ca6ab3c3211cacd023da8d7b48L4 is not on crates.io yet, but I think it’s breaking for dependents like glutin who rely on the Encode trait being implemented for libc types. That’s OK for c_char which is just a type alias of u8 or i8, but not for c_void which is unfortunately a different type in std::os::raw and libc: rust-lang/libc#71

I’d recommend bringing back the libc dependency (unfortunate, but the alternative will be a pain) and implementing the trait for both c_void types.

[SSheldon]

There's no reliable way to implement a trait on a libc type that'll be available to users, unless you lock your crate to only using a specific version of libc and make your users do the same. Trying to implement traits on libc types was what caused a breakage in glutin previously.

Since we can't be sure that users will be on the same version of libc as this crate, it seems better to not promote that functionality and just use the stdlib types. I don't want to try to lock users of this crate into a specific version of libc, so I'd rather just remove support for the libc types entirely.

Does that change what you think of the situation, @SimonSapin?

[SSheldon]

And I was expecting this to be a breaking change, and was planning to publish the next version as 0.2 accordingly :)

[SimonSapin]

Fair enough.

@tomaka, should glutin switch to std::os::raw too?

[tomaka]

Yeah glutin could switch to std::os::raw.
The only problem is that it's a breaking change, and I'm a bit reluctant about pushing new major versions too often.

[SSheldon]

This was a breaking change and was published in the new 0.2 release, closing this out.