Remove `T: Sized` on pointer `as_ref()` and `as_mut()`

[cuviper]

NonZero::is_zero() was already casting all pointers to thin *mut u8 to check for null. The same test on unsized fat pointers can also be used with as_ref() and as_mut() to get fat references.

(This PR formerly changed is_null() too, but checking just the data pointer is not obviously correct for trait objects, especially if *const self sorts of methods are ever allowed.)

[rust-highfive]

r? @alexcrichton

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

[bluss]

This is UB (null in a &[u8]) so unfortunately can begin to fail when the compiler gets smarter.

[cuviper]

Is there any better way to get a null unsized pointer? Or are they impossible to be null in practice? If the latter, we could just drop those parts of the tests.

[cuviper]

I suppose I could implement a local Repr hack for the tests, similar to slice::from_raw_parts but without ever calling it a &.

[cramertj]

Depending on how much you hate transmute, you could do let ncs: *const [u8] = unsafe { mem::transmute((0usize, 0usize)) };

[cuviper]

I went ahead and added a transmute with Repr, which I think is a little safer than a tuple because it can be #[repr(C)]. This is just for testing anyway, so whatever we do isn't going to affect anyone in the wild.

[cuviper]

@bluss also pointed out that it could be surprising that there are many possible null values for fat pointers. I added docs mentioning this, but if that's too weird, we could back off to just unsized as_ref and as_mut, leaving is_null sized.

[bluss]

To do the null pointer right (via @eddyb): ptr::null::<[u8; 4]>() as *const [u8] or other unsizing coercions.

[alexcrichton]

Looks great to me! Since this'll be instantly stable, let's....

@rfcbot fcp merge

[rfcbot]

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

• @BurntSushi
• @Kimundi
• @alexcrichton
• @aturon
• @dtolnay
• @sfackler

Concerns:

• go (#44932 (comment))

Once these reviewers reach consensus, 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.

[eddyb]

You don't need this: you can just cast null_mut::<[T; 0]>() to *mut [T].

EDIT: ah yes I see that @bluss commented about this already.

[cuviper]

OK, it now uses coercion to get the null pointers, and I added trait objects this way too.

[dtolnay]

This is not the behavior that Go has for comparing interfaces (read: traits) against nil (read: null). Are we sure the behavior in this PR is useful? How does Go justify their behavior and do they regret it?

The as_ref / as_mut changes seem fine.

package main

import "fmt"

type S struct {}

func (*S) String() string {
	return "S"
}

func main() {
	var s fmt.Stringer = (*S)(nil)
	fmt.Println(s == nil) // false
}

@rfcbot concern go

[eddyb]

@dtolnay Currently it is UB to have a null vtable pointer, it's as if *mut Trait and &mut Trait / Box<Trait> all have the same safe &'static VtableForTrait pointer as the fat metadata.

[cuviper]

@dtolnay Note however that this isn't changing PartialEq behavior. That's why I added the doc note that two is_null pointers may not compare equal.

I don't really know Go. If you have such a nil-initialized interface pointer, is there no way to tell if it's actually nil? (thus shouldn't be called)

[dtolnay]

Re: @cuviper

If you have such a nil-initialized interface pointer, is there no way to tell if it's actually nil? (thus shouldn't be called)

By design, it is not easy to tell if the data pointer is nil. This can be confusing but it is because interfaces with a nil data pointer are totally fine to call interface methods on -- as long as those methods do not lead to the nil pointer being dereferenced. In the code above, calling s.String() is fine even though the data pointer in s is nil. It invokes the String method on *S passing nil as the receiver.

If checking the data pointer for nil is really what you mean, there are some ways. But as I understand it, this would be very unusual in Go code (which is why I was startled to see us define ptr::is_null this way).

// use type assertion to check for nil data pointer of a particular type
p, ok := s.(*S)
if ok {
	isNil = p == nil
}

// use reflection to check for nil data pointer of any type
isNil = reflect.ValueOf(s).IsNil()

---

Re: @eddyb

Currently it is UB to have a null vtable pointer

Do you have any sense of what the future holds here? In particular, I would be concerned about how this PR interacts with the following two potential changes:

• We allow ptr::null to support T: ?Sized by returning a null vtable pointer.

  ptr::null::<ToString>()

• As part of pointer-related unsafe ergonomics in rust-lang/rfcs#433, we allow methods to take self by *const or *mut and this is object-safe.

  trait Trait {
      unsafe fn f(*const self);
  }

In combination, these would put us in a state like Go where checking for null data pointer is almost never what you want and checking for null data pointer + null vtable is almost always what you want.

Have there been any discussions that would rule out one or both of these from being pursued in the future?

[cuviper]

If Rust ptr::null starts returning null vtables too, then == null() should suffice for users to check for this case. Then as_ref and as_mut can still be used to check for null data, assuming a good vtable. But what can one do for the possibility of (non-null data, null vtable)?

But even with the possibility of trait Trait { unsafe fn f(*const self); }, I think it's still useful and not too surprising for is_null() to return true for a null self, even if that fat pointer has a concrete vtable. It seems fine to me that one should use == null() to check for totally null, and document the distinction. I think it's an improvement over Go to be able to check both meanings of null (without reflection).

Slices are weird too. ptr::null would probably return 0 length, but == null() is not as useful here, as you may have a null pointer with other lengths. For this I think it makes sense that is_null only cares about the data pointer.

---

If we want to defer a decision on is_null, I'd be OK with just as_ref and as_mut for now.

[dtolnay]

what can one do for the possibility of (non-null data, null vtable)?

I think that can't happen.

I think it's still useful and not too surprising for is_null() to return true for a null self, even if that fat pointer has a concrete vtable.

I don't yet agree that this would be useful. Do you have a use case in mind where the best solution involves checking whether the data pointer of a trait object is null? It is possible that these are universally better served by some combination of not using trait objects, using as_ref / as_mut, or checking null data pointer + null vtable.

[cuviper]

If nothing else, I think as_ref and as_mut are more easily explained in terms of an is_null check which the user could also perform manually, but it's not a big deal.

[eddyb]

I don't think we'll ever see distinct requirements for validity of metadata between safe and unsafe pointers if we get any kind of Custom DSTs, because of the high complexity associated with having it not be uniform and requiring potentially user-defined conversions for casts which are builtin now.

As for trait Trait { unsafe fn f(*const self); } I don't see how that changes anything? You still need a valid vtable to call the method, in fact it makes having a valid vtable even more important.

[dtolnay]

As for trait Trait { unsafe fn f(*const self); } I don't see how that changes anything?

This is what makes Go's choice of behavior for == nil make sense -- see the code above with (*S)(nil). In Go if you have a trait object, by convention you get to assume that it is either completely nil including vtable, or it is a valid implementation of the interface. Whether or not the data pointer is nil is none of your business. If the caller gave you a trait object with nil data and non-nil vtable, it is the caller's responsibility that calling the trait methods with a nil data pointer is fine.

Transliterated into Rust it would be:

struct S {}

impl Trait for S {
    unsafe fn f(*const self) -> &'static str {
        "S"
    }
}

fn main() {
    let s: *const Trait = ptr::null::<S>();
    println!("{}", s.is_null()); // false, calling Trait::f is fine

    let s: *const Trait = ptr::null::<Trait>();
    println!("{}", s.is_null()); // true, calling Trait::f is not fine
}

[xfix]

@dtolnay

This is not the behavior that Go has for comparing interfaces (read: traits) against nil (read: null). Are we sure the behavior in this PR is useful? How does Go justify their behavior and do they regret it?

https://golang.org/doc/faq#nil_error

Considering advice like "It's a good idea for functions that return errors always to use the error type in their signature (as we did above) rather than a concrete type such as *MyError, to help guarantee the error is created correctly.", I can imagine this being a design mistake.

As for why it happens, it's because there is no explicit is_nil function for interfaces, but rather a comparison is used. For instance, assuming p is interface{}((*int)(nil)) (interface of *int type and nil value).

p == nil

The types of comparison have to be identical, so an implicit cast is inserted

p == interface{}(nil)

An interface is pair of a type pointer and a value. As nil is a value that exists in multiple types, Go doesn't try to assume any particular type, and just uses null pointer as type name.

Essentially this makes it a comparison like the following (this is pseudo-Go).

(*int, nil) == (nil, nil)

nil is a different type than *int, so comparison does fail.

A type needs to be compared while comparing 2 interfaces, as Go does provide value types. For instance, the following program returns true and false.

package main

import "fmt"

func main() {
	fmt.Println(interface{}(int(2)) == interface{}(int(2)))
	fmt.Println(interface{}(int(2)) == interface{}(uint(2)))
}

Considering Rust doesn't allow null vtable pointers, has a function checking for null pointers instead of a comparison, and *const Trait being always implemented as pair of 2 pointers (not required by Go) this doesn't sound like an issue for Rust, as long std::ptr::null cannot be used to directly create trait objects pointers.

To be precise, 0 as *const ToString and std::ptr::null::<ToString>() must be an error to avoid this issue (and it currently is) - language needs to require specifying any type that implements a trait, for example std::ptr::null::<i32>() as *const ToString.

[dtolnay]

@xfix we agree that the is_null behavior in this PR makes sense in Rust today. I disagree that we definitively never want to support ptr::null::<Trait>() in the future. I would prefer to contextualize that decision in the broader discussion around raw pointer ergonomics in rust-lang/rfcs#433.

[cuviper]

I pushed an update to restore is_null, so we can leave that as an open design question. Now this PR is only unsizing as_ref and as_mut.

[dtolnay]

@ExpHP this PR affects ?Sized types where it is not so clear-cut. In the code from #44932 (comment) I would expect as_ref to return Some in the first case and None in the second case, even though both data pointers are null. With something like custom DSTs from rust-lang/rfcs#1524 things get even stranger. Basically there is a discussion around raw pointer ergonomics that hasn't happened yet and I don't feel comfortable painting ourselves in a corner that we know (from Go) does not necessarily make sense. I would prefer to better understand the design space around raw pointers before making decisions about the semantics, which is tracked in part in rust-lang/rfcs#433.

[ExpHP]

My comment concerns the semantics not of pointers, but of borrows. I am saying that, because ptr.as_ref().is_none() constructs a borrow in the case where it returns true, there are only two possibilities for how it could behave on a null data pointer with a non-null vtable:

• it returns false, or
• it formats your hard drive.

is_null() is completely different, because it does not create a borrow.

[bluss]

@ExpHP Yes, it seems necessary to produce None in that case. It seems it is unresolved if there are other cases that also produce None.

[dtolnay]

@ExpHP @bluss in #44932 (comment) I would expect the first case to produce Some with a null data pointer and a non-null vtable. By Go's logic, the fact that the caller passed a non-null pointer *const Trait gives callee permission to call trait methods on it -- whether the data pointer is null is none of the callee's business.

EDIT: disregard, this would not make sense

[ExpHP]

@dtolnay so if I understand your responses correctly, you want the following to be on the table as well? (i.e. allow not just raw pointers, but also borrows to have null data):

struct S {}

impl Trait for S {
    // Notice: &self, not *const self
    fn f(&self) -> &'static str {
        "S"
    }
}

fn main() {
    // Notice: &Trait, not a raw pointer
    let s: &'static Trait = unsafe { ptr::null::<S>().as_ref().unwrap() };
    println!("{}", s.f());
}

[dtolnay]

@ExpHP that code is stable already so changing it would not be on the table.

I read your comments again and I find the point about as_ref constructing a borrow compelling. I see why that means as_ref and as_mut are not problematic the way is_null is. Thanks for spelling it out for us! That + removing is_null from the PR resolves the concern I had so I think we can try this again (I will copy over the previous checkboxes).

@rfcbot fcp merge

[rfcbot]

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

• @BurntSushi
• @Kimundi
• @alexcrichton
• @aturon
• @dtolnay
• @sfackler

No concerns currently listed.

Once these reviewers reach consensus, 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.

[carols10cents]

@BurntSushi ticky box here waiting for you!

[rfcbot]

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

[alexcrichton]

@bors: r+

[bors]

📌 Commit 604f049 has been approved by alexcrichton

[alexcrichton]

@bors: r+

oops...

[bors]

💡 This pull request was already approved, no need to approve it again.

• There's another pull request that is currently being tested, blocking this pull request: #45822

[bors]

📌 Commit 604f049 has been approved by alexcrichton

[bors]

⌛️ Testing commit 604f049 with merge ee22861...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing ee22861 to master...