Should `Vec::as_ptr()`/`Vec::as_mut_ptr()` return nullptr instead of the dangling value?

[cmazakas]

In Rust's stdlib, the only way to know if the return from as_mut_ptr() is to check the .capacity() of the Vec.

While this is fine on its own, it does create an interesting interaction with system's APIs which expect either NULL or a valid pointer.

I think updating .as_ptr() and .as_mut_ptr() to return nullptr in the case of capacity() == 0 could help marginally reduce errors when using external APIs written in C or C++ where this idiom is common. There's a lot of debug checking that will specifically check for NULL but this isn't possible when the pointer's value is 0x1, as an example.

[saethlin]

This isn't going to happen. These functions are trivial accessors; so I'm sure if we added logic to them that would cause a number of performance regressions in the wild. More importantly though, returning null just trades off one bug for another; any code doing NonNull::new(vec.as_ptr()).unwrap() would now have a problem.

[ChrisDenton]

We could have a new function that returns an Option<NonNull> or something like that which then has an additional guarantee not to be dangling. But that would need an API Change Proposal and a clear motivation.

[cuviper]

We could have a new function that returns an Option<NonNull> or something like that which then has an additional guarantee not to be dangling.

... except for ZSTs which are always dangling, and always usize::MAX capacity.

[ChrisDenton]

For ZSTs, such a function could just always return None. How useful that would be I don't know.