Tracking issue for <*mut T, *const T>::{as_ref, as_mut_ref}

[alexcrichton]

This is a tracking issue for the unstable ptr_as_ref feature of the standard library. These functions allow unsafely converting raw pointers to optional safe references, returning None if they're null.

I would personally vote for removing these, but there's certainly some usage throughout the standard distribution.

cc @gankro

[Gankra]

People really really really _really_ like using Options for anything that "might" be. null is a standard sentinel value, and this promotes it to an Option (as a no-op, no less!). I'd rather people abuse this than Option<NonZero<*const T>>.

Historically I recall you arguing against it because raw pointers can be invalid in so many other ways. But that seems immaterial here. When you're calling this you're asserting that the only way it can be invalid is if it's null -- which is a really common pattern.

Surely this is something FFI encounters a lot?

[alexcrichton]

I have personally never felt the need to use these functions, I've always just done if ptr.is_null() { ... } else { ... }, converting it to an option and then using something like map isn't something I've done that often.

converting it to an option and then using something like map isn't something I've done that often.

This is actually really useful in concurrent lock free hashtables where the hash points to an atomic pointer. This means you end up iteratoring across a list of atomics [1], which is a nice clean recursive operation with the old Option syntax.

I guess it is just syntax, but here mapping the Option vaule is pretty nice.

[1] Data Structure described: https://www.youtube.com/watch?v=HJ-719EGIts

[pythonesque]

I have personally never felt the need to use these functions, I've always just done if ptr.is_null() { ... } else { ... }, converting it to an option and then using something like map isn't something I've done that often.

I find them quite frequently useful, and it appears that others do as well. To be honest, I'm not sure what the justification for removing it is anyway. If anything we should be adding more sugar to raw pointers, not removing what already exists.

[bholley]

I came across this issue while working on Gecko/Servo layout bindings, which involves heavy FFI usage.

My first implementation looked like this:

fn root_node(&self) -> Option<GeckoLayoutNode<'ld>> {
    unsafe {
        let root = Gecko_RootNode(self.document);
        if root.is_null() {
            None         
        } else {         
            Some(GeckoLayoutNode::from_raw(root))
        }                
    }                    
}

With as_ref, I was able to transform it to:

fn root_node(&self) -> Option<GeckoLayoutNode<'ld>> {
    unsafe {
        Gecko_RootNode(self.document).as_ref().map(|n| GeckoLayoutNode::from_ref(n))
    }                                                                         
}

Which is a heck of a lot nicer.

[alexcrichton]

🔔 This issue is now entering its cycle final comment period to be handled in 1.8 🔔

The libs team is somewhat on the fence about this method, and we figured that the FCP can serve as a good opportunity to foster discussion around these methods!

[bholley]

Most of the discussion in this thread so far is about why they are useful and convenient. Can you elaborate on the rationale for removing them?

[alexcrichton]

I think that I'm probably one of the bigger proponents for their removal, so certainly!

I certainly agree that these methods can be nice to use from time to time, but I have personally never actually found a case where I ended up using them in the long run. I'm a little unsettled by the only invalid pointer is the null pointer (when there's a whole bunch of other invalid values), and to me this kinda sticks out as an initial attempt at "nicer unsafe programming" but doesn't seem quite fleshed out.

I would be more comfortable if we had a comprehensive story about ergonomically working with raw pointers. @gankro's initial stab with raw-rs I think is a great start here. Starting with just as_ref, however, seems a little odd to me.

Now I definitely don't feel super strongly either way on this, however. If others find these methods quite useful, then I'd be fine stabilizing.

[SimonSapin]

I'm a little unsettled by the only invalid pointer is the null pointer (when there's a whole bunch of other invalid values)

I think you’re looking at this differently than the people who use these methods. The point is that in some cases, null is not invalid, it’s used to represent the absence of something. (Some other invariant is used to make sure other invalid pointers don’t occur, for example "this field is private and only ever set to ptr::null() or Box::into_raw(something)". Business as usual when using raw pointers at all.)

Now, you could argue that people should not use null as an expected raw pointer value and should use something like Option<NonZero<*const T>> instead, but NonZero is not stable and it’s unclear if it’s ever going to be.

I would be more comfortable if we had a comprehensive story about ergonomically working with raw pointers. @gankro's initial stab with raw-rs I think is a great start here.

raw-rs looks nice but largely unrelated. I don’t see anything related to null-as-an-expected-value in it.

The main use case is handling return Null pointers. But I understand the concern with other forms of pointer invalidation.

If raw-rs pans out could it be integrated into the Option return value? Or is returning invalid pointers something that stabilizing on could potentially bite the project? (I can't think of a use case for this but I also haven't had coffee yet this morning).