Method for `Option<&T>` that converts to `*const T`

[jmegaffin]

I find myself often wanting to go from an Option<&T> to a *const T, which SHOULD be an easy and safe conversion, as every Option<&T> is guaranteed to correspond a *const T identical to it in representation. We already have a conversion, std::pointer::as_ref, the other way around, so I find it strange that the shortest way to do so (without defining a new function) is this:

.map_or(ptr::null(), |x| x)

It's just as easy to do the same for Option<&mut T> -> *mut T, of course, although I can't see the utility in it.

It's not as fundamental as Option<&T> -> *const T, but it would also be nice to have Option<&CStr> -> *const c_char.

[durka]

Well, you can't have both Option<&T> -> *const T and Option<&CStr> -> *const c_char, those conflict.

[oli-obk]

Well, you can't have both Option<&T> -> *const T and Option<&CStr> -> *const c_char, those conflict.

if T: Sized that would be possible.

[jmegaffin]

@durka, they could also be named differently.

[wycats]

I find myself often wanting to go from an Option<&T> to a *const T

I also find myself wanting this from time to time. You're right that it seems that ptr.as_ref() should be symmetric with option.as_ptr(). We already have a decent amount of as_ptr() methods in std; can anyone see a reason not to have this one?

[wycats]

For what it's worth, the reason I say that I want this "from time to time" (rather than frequently) is that when writing new extern "C" functions, I use Option<&T> and Option<Box<T>> directly, and call them from C with nullable pointers.

The reason I like this approach is that it documents the requirements on the C code directly in the signature, and the Rust code simply assumes that the C code is following the rules that the Rust compiler would normally have enforced.

I gave a talk about this at RustCamp (Using Rust from C... or Any Language).

[mark-i-m]

Maybe I'm just ignorant, but it seems a bit niche to me, and I think that Option already has a very inelegant API, though I'm not sure how to fix it...

[tmccombs]

I'd also like to see this added.

A more generic approach would be to define an AsPtr trait which is implemented for pointer types that currently have as_ptr (&T, RefCell<T>, Cell<T>, &str, '&CStr) and then there can be an implemention of AsPtrforOption<T: AsPtr>`.

Then there could be a complementary trait IntoRaw (or IntoPtr) that takes ownership of the input and returns a pointer (so it would be implemented by Box<T> and CString) and there could be an implmentation of IntoRaw for Option<T: IntoRaw>.

Another advantage of this is that to_ptr and into_raw would work for custom pointer types.

[tmccombs]

I wrote a crate that implements the traits I mentioned: https://github.com/tmccombs/ptrplus

[thenewwazoo]

I encountered this desire today in an embedded context. I've got C functions being called from a no_std crate that take pointers to void arguments, and being able to turn an Option<T> into a *T (to be passed around as a *const cty::c_void) would be immensely useful. (My first attempt to solve the problem was impl<T> From<Option<T>> for *const cty::c_void.)