Implement Default for raw pointers

[ChrisDenton]

ACP: rust-lang/libs-team#571

This is instantly stable so we will need an FCP here.

Closes rust-lang/rfcs#2464

[rustbot]

r? @tgross35

rustbot has assigned @tgross35.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[tgross35]

Implementation looks good to me, cc @rust-lang/libs-api for FCP consideration.

@rustbot label +I-libs-api-nominated

[Amanieu]

@rfcbot merge

[rfcbot]

Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[scottmcm]

Something I only thought of now, despite commenting on the ACP:

What are the trade-offs compared to using = ptr::null() for this, with rust-lang/rfcs#3681 ?

My "look it's a C struct" examples would arguably be fine defaulting it in the struct definition instead, since they know it's definitely a pointer.

How often is this wanted on generics vs concrete things?

---

Trying to find this PR again I accidentally found this from @joshtriplett:

Null isn’t necessarily a reasonable default value for a pointer. Some users of pointers may expect a potential null; other users may expect a valid pointer and explode on a null.

[ChrisDenton]

Hm, even with default field values I still think it good to have sensible defaults even if you may want to override them.

As for the risk, I'm not personally persuaded that this adds any atm but could be wrong. std::ptr::null is a safe function already and mem::zeroed is fairly inconspicuous amongst other unsafe code so if code would blow up on nulls then you need to be enforcing that it doesn't happen somehow. I don't think this PR materially changes that.

I also don't think defaulting to null is even mildly surprising. Even if you ignore all the other languages, Rust's primitive's tend to default to the zero bit pattern even if that doesn't make sense as a default. E.g. the default bool is false. the default char is \0, etc. In any case we do already have AtomicPtr defaulting to null so there is a strong precedence.

[bors]

☔ The latest upstream changes (presumably #137412) made this pull request unmergeable. Please resolve the merge conflicts.

[LegionMammal978]

How often is this wanted on generics vs concrete things?

At least in my case, I was implementing native methods for jni-sys. When a JNI native method throws a Java exception, it typically calls a JNI function to register the exception, then returns the logical zero value for its return type. This can either be a zeroed integer, an f64 equal to 0.0, or a null jobject. I was writing a generic wrapper that turned Rust panics into Java exceptions on the boundary, but I found that T: Default didn't work for a jobject return type, since it's a typedef for an opaque *mut _jobject. I ultimately ended up writing a separate trait for zero values that included jobject pointers.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[ChrisDenton]

Implementation looks good to me

The final comment period, with a disposition to merge, as per the review above, is now complete.

@bors r=tgross35

[bors]

📌 Commit 830bd8b has been approved by tgross35

It is now in the queue for this repository.