implement `Default` for raw pointers

[ChrisDenton]

Proposal

Problem statement

Pointers do not implement Default despite there being a natural default value (as shown by is_null). Default is however implemented for AtomicPtr.

Motivating examples or use cases

This works nicely, with all the primitives being zeroed by default:

#[derive(Default)]
struct Test {
    a: [u8; 6],
    b: bool,
    c: char,
    u: u32,
}

But if you add a pointer:

#[derive(Default)]
struct Test {
    a: [u8; 6],
    b: bool,
    c: char,
    u: u32,
    p: *const u8
}

Then you get this error:

error[E0277]: the trait bound `*const u8: Default` is not satisfied
 --> src/lib.rs:7:5
  |
1 | #[derive(Default)]
  |          ------- in this derive macro expansion
...
7 |     p: *const u8,
  |     ^^^^^^^^^^^^ the trait `Default` is not implemented for `*const u8`
  |
  = help: the trait `Default` is implemented for `u8`

To workaround this, each struct containing a pointer can manually implement Default instead of deriving it. The safe way to do so is quite verbose, especially when structs get larger:

impl Default for Test {
    fn default() -> Self {
        Self {
            a: [0; 6],
            b: false,
            c: '\0',
            u: 0,
            p: std::ptr::null()
        }
    }
}

So people will often reach for unsafe to make life easier:

impl Default for Test {
    fn default() -> Self {
        unsafe { std::mem::zeroed() }
    }
}

This is more succinct (if still more verbose than a derive), however now we've introduced a completely unnecessary use of unsafe. This matters because now the guard rails are off. It won't protect you if there are values that cannot be zeroed (there are some lints that can help but they necessarily can't catch everything).

Solution sketch

Note: These will be instantly stable.

impl<T: ?Sized + Thin> Default for *const T {
    fn default() -> Self {
        crate::ptr::null()
    }
}

impl<T: ?Sized + Thin> Default for *mut T {
    fn default() -> Self {
        crate::ptr::null_mut()
    }
}

Alternatives

The status quo.

Links and related work

• Implementing this would mean Default could (safely!) be used in similar situations to C's = {}; initialiser without needing more than a derive.
• Default is not implemented for raw pointers (*const and *mut) rfcs#2464

What happens now?

This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.

Possible responses

The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):

• We think this problem seems worth solving, and the standard library might be the right place to solve it.
• We think that this probably doesn't belong in the standard library.

Second, if there's a concrete solution:

• We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.)
• We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.

[scottmcm]

Defaulting raw pointers to null does seem reasonable, as especially repr(C) types that in C would be initialized with = {}; would generally expect to default to null.

That said, I suppose one could argue that the same effect can be obtained with Option<NonNull<T>>, and letting that default to None that's guaranteed to be null in representation.

[clarfonthey]

I guess that probably the biggest downside to Option<NonNull<T>> is the variance applied even for mutable pointers which might not be desired, although if you're working with raw pointers anyway that's probably not even a consideration, since you're probably just working with POD types anyway.

I kind of feel like Option<NonNull<T>> is probably a substantially more suitable type than raw pointers in most cases, although it definitely is less ergonomic. I don't think that it'd be too harmful to allow Default for raw pointers in the meantime for that reason, especially considering how stuff generated from C bindings will likely use raw pointers instead of Option<NonNull<T>>

[kennytm]

previous discussion rust-lang/rfcs#2464

[Amanieu]

We discussed this in the @rust-lang/libs-api meeting and are happy to accept this. I've started an FCP on the PR (rust-lang/rust#139535).