Separate the FFI-safe types from the rest of the crate

[PonasKovas]

Hello, first of all, thanks for this amazing crate.

In my project, I find your #[repr(C)] equivalents of common types from std and such (RVec, RString, etc) very useful, however - everything else on this crate - not so much.

I was wondering if it would be possible to separate the abi_stable::std_types module to a separate crate, that would just provide #[repr(C)] types and a simple numerical ABI_VERSION constant. That would make things much simpler for my project (and others, my case is definitely not the only one), help compilation times and so on. Making modular libraries is always a good practice.

[PonasKovas]

I have started working on my own, more minimal package that provides #[repr(C)] equivalents of common types: safe_types

[marioortizmanero]

Very interesting! I would still leave this open, since it would be a great idea in case someone has the time to do it. Though it would indeed be quite complicated, since sabi_types heavily relies on the macros. May I ask, how are you going to implement SCow so that you don't get the same issue as in #75? I think that's still pending, right?

[PonasKovas]

I haven't implemented Cow yet, and it's not a priority for me, since I'm implementing things in the order that I need them in another project. When I get to it, I will look more into it.

[marioortizmanero]

I haven't implemented Cow yet, and it's not a priority for me, since I'm implementing things in the order that I need them in another project. When I get to it, I will look more into it.

No problem, just make sure it's not invariant when you write it, or you'll run into problems. Your already implemented RVec<T> should use NonNull<T> instead of *mut T for the same reason.

[PonasKovas]

@marioortizmanero If you're still interested,

I implemented Cow in my safe_types. I haven't looked at your implementation in depth, but on the first glance it looks like I took a different approach.

[marioortizmanero]

Nice! Yeah, different design, but I think you don't have the invariance issues with it. Our design ended up being quite similar, but I would say ours is a bit more flexible, at the cost of being harder to implement/use.