Miss Dada  🏳️‍⚧️

It doesn't have a different memory repr, but it does have narrowed provenance for the pointer you get. That's why the as_ptr method for slices first makes *const [T] and then makes *const T, in that very specific ordering. Sounds stupid, but RalfJ assures me it's true.

Wow that basically eliminates the ability to have a safer version of `as_ptr` for many types then. That's really unfortunate.

Does it? Why can't it be a transparent type that is basically just the pointer, but has a PhantomData reference to the original CStr?

Because a transparent type that is basically just the pointer can't be passed to a function that takes a pointer

Well yeah, my argument is still to have that type in the function signature as well, so you never touch a raw pointer at all

Sure, but now you have to change both `CString` *and* whatever it's being passed to, which you may or may not have control of. So I can't just release a "better CString" crate, I also have to release a "better libc" or whatever else to go along with it.

There's a ton of code out there that works with raw pointers, expecting all of those signatures to change is a pipe dream IMO

Libc, maybe not, smaller APIs might work. like you can make a better curses api fairly easily or whatever.