std: Second pass stabilization for ptr

[alexcrichton]

This commit performs a second pass for stabilization over the std::ptr module.
The specific actions taken were:

• The RawPtr trait was renamed to PtrExt
• The RawMutPtr trait was renamed to PtrMutExt
• The module name ptr is now stable.
• These functions were all marked #[stable] with no modification:
  • null
  • null_mut
  • swap
  • replace
  • read
  • write
  • PtrExt::is_null
  • PtrExt::is_not_null
  • PtrExt::offset
• These functions remain unstable:
  • as_ref, as_mut - the return value of an Option is not fully expressive
    as null isn't the only bad value, and it's unclear
    whether we want to commit to these functions at this
    time. The reference/lifetime semantics as written are
    also problematic in how they encourage arbitrary
    lifetimes.
  • zero_memory - This function is currently not used at all in the
    distribution, and in general it plays a broader role in the
    "working with unsafe pointers" story. This story is not yet
    fully developed, so at this time the function remains
    unstable for now.
  • read_and_zero - This function remains unstable for largely the same
    reasons as zero_memory.
• These functions are now all deprecated:
  • PtrExt::null - call ptr::null or ptr::null_mut instead.
  • PtrExt::to_uint - use an as expression instead.

[rust-highfive]

r? @pcwalton

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

r? @aturon

[aturon]

Can you change this to say: Option is not clearly the right return type, and we may want to tie the return lifetime to a borrow of the raw pointer.

[aturon]

r=me modulo tiny nit

[alexcrichton]

deleting r+ for now, I'd like to take some more time to analyze https://github.com/Gankro/raw-rs/blob/master/src/rawptr.rs

[Gankra]

CC me

[alexcrichton]

Ok, after thinking about this and talking it over with @gankro, I'm thinking the following:

• Adding the free-functions as methods on the PtrExt or PtrMutExt trait would be nice, but does lead to duplication. There's also a desire, however, to keep the duplication due to the free-functions allowing for coercion.
• Some functions may wish to be renamed, such as copy_memory => copy, set_memory => write_bytes, etc.
• Other convenience methods like add and sub for the offset function taking a uint instead of an int.

For now the functionality stabilized here I believe is a subset of the possible future functionality, and I think we can let feedback during the first alpha cycle to drive the rest of what we stabilize in this module.

Does that sound ok @gankro?

re-r? @aturon

[aturon]

Can this be dropped in favor of !p.is_null()?

[aturon]

r=me modulo nits.

[Gankra]

Sounds okay, but the renames are a back-compat issue, no?

[aturon]

@gankro

Sounds okay, but the renames are a back-compat issue, no?

Neither are being stabilized here, FWIW.

[Gankra]

Not sure if it matters, but they are compiler intrinsics.