RFC: Make `*T` not nullable

[nikomatsakis]

I think the fact that *T is nullable is an anachronism (or will be once #10570 is fixed). We should just use Option<*T> for nullable pointers. Anybody else have an opinion?

Nominating.

[sfackler]

I feel a little weird having Rust types like Option "infect" C FFI bindings, but nullable function pointers are currently done with Option<extern "C" fn()> so it'd at least be consistent with that.

[pnkfelix]

We need to discuss this further, there are interesting issues on both sides of this. P-backcompat-lang.

[nikomatsakis]

Some comments:

• Scalar casts might have to go, since you could do 0 as *T. iirc
  casting integers to *T is mostly allowed for embedded null in static
  constants, the need for which goes away here.
• The reason Option<*T> should be represented as a pointer #10570 wasn't implemented was precisely because *T is nullable and hence Some(null) is a "legit" value.

Upside of the change:

• More accurate types
• Static constants can write Foo { x: None } instead
  of Foo { x: 0 as *uint }

Downside of the change:

• Extern bindings would have to say Option<*T> if
  they want to accept null

[nikomatsakis]

See some discussion in #9788

[glaebhoerl]

I like this a lot. (It's similar to what I tried proposing a few months ago.) I think the mentioned downside is an upside. It should be explicit whether nulls are possible or not. Why should it be different for *T than any other type?

If we do this then the Option optimization would also automatically apply to user-defined types written in terms of *T, and if we also do the thing where *T is multi-word for unsized types, then basically people can just use *T in a natural way and everything else gets taken care of.

[Aatch]

My issue with this is that I consider the current enum-pointer optimization to be just that, an optimization, and relying on that behaviour doesn't sit right with me. Currently, Option<~T> just happens to be represented as a nullable pointer, but if it wasn't all current Rust code should continue working as before.

I am firmly against anything that makes *T behave noticeably differently in any way, shape or form to some C pointer. I always considered raw pointers to be the place where Rust just left you alone to do your own thing.

This also, for some reason, singles out 0 as a bad value. The whole point of the raw pointers is that Rust cannot determine if they point to any valid location. Why should we treat 0 as special in this case? What about other bogus pointers? What about tagged pointers? They aren't safe either and I don't see how dubiously preventing NULL gains anything other than overhead and the illusion of safety. Because it's not like this actually prevents *T from being NULL, it just prevents you from constructing one. If I forget to wrap my pointer return in an Option, somebody could assume that NULL isn't a possible value, even though that isn't true. Or I could pass a **T through and have that be turned to null.

I can see this only producing misleading code and faulty assumptions. Canonicalising Option<*T> as "null raw pointer" only muddies the water because the implication, that *T is not null, isn't true.

If Option<*T> is implemented as a nullable pointer, I'm not too worried, but I am firmly against making Option<*T> the nullable pointer.

[lilyball]

I extremely strongly agree with @Aatch. Making *T non-nullable seems to violate the entire point of *T.

[apoelstra]

I also agree with @Aatch. *T already signifies "here be dragons". Let's at least make sure the dragons have C semantics.

[jruderman]

I approve of this change. It will ensure that writers of C bindings document their assumptions and that their code is consistent with their assumptions. In debug builds, Rust could automatically insert assertions to test these assumptions (e.g. that certain C functions never return null).

Why should we treat 0 as special in this case? What about other bogus pointers? What about tagged pointers?

They are not pointers! They should be represented by corresponding Rust types depending on how they differ from pointers (both 0 and 1 are special; low bits are meant to be lopped off; etc). In the worst case, they can be represented in Rust as (newtyped) uints.

[thestinger]

This could be really annoying in kernel code where 0 isn't a special pointer. LLVM currently lacks full support for this, but it will get there.

[glaebhoerl]

Because it's not like this actually prevents *T from being NULL, it just prevents you from constructing one. If I forget to wrap my pointer return in an Option, somebody could assume that NULL isn't a possible value, even though that isn't true. Or I could pass a **T through and have that be turned to null.

If this is referring to extern functions, then it's an objection I was going to raise myself before I realized that it's true of any type. The signatures of foreign functions are not checked in any way and it's entirely the programmer's responsibility to get them correct. If she doesn't, then implicit transmute()s will happen left and right, and Option<*T> to *T is no more special in this sense than any of the other possibilities.

If Option<*T> is implemented as a nullable pointer, I'm not too worried, but I am firmly against making Option<*T> the nullable pointer.

How then would you distinguish Some(0) from None?

I don't get the attachment to C semantics, either. We have no trouble learning from C's mistakes in other parts of the language. Where else in the semantics (not syntax) of the language do we say "we have to do it this way because C does it this way, period", even if another way might be better? Why here?

Finally, do (plural) you feel the same way about function pointers, where the same things (non-nullable, need Option) are true?

Things I agree with are that writing the null pointer optimization in stone and assuming 0 is an invalid value even when it's not necessarily (e.g. kernels) isn't super, but I feel that these are smaller problems than the benefits.

One further concern I would raise from an ergonomics perspective, overlapping with but not quite the same as things above, is that if it looks like a C pointer, and it sure does, then people are going to expect that it behaves like a C pointer (to some degree this might already be apparent). They're going to think it's the same thing as in C and use it in their extern fns indiscriminately, suffer unpleasant effects, and get really surprised when they learn that they have to wrap it in Option when null is an option. To avoid falling into uncanny valleys, if the semantics change, then maybe the syntax should too.

[Aatch]

@glehel I don't like the idea of pushing systems concerns further to the side in a systems programming language. There needs to be some type that you can use to directly deal with the hardware without Rust sticking it's nose in. We have pointers that don't follow C semantics. We do need one that does. This isn't something we can change, we have to deal with C code.

As for other values being passed to extern code being made into illegal values, yes, you're right, but in those cases either some has gone terribly wrong or you are making a terrible mistake.

My issue is that it gives the illusion of safety where it's blatantly false. It's basically saying "these pointers are never null, except when they are", because it's not like the compiler will catch the little things like forgetting to wrap some type in an Option.

Lastly, what, in light of these criticisms, would this change gain you? It doesn't make raw pointers any more safe. It doesn't make writing FFI bindings any easier, it could help catch a class of errors, but only by introducing a new class. All it does, to me, is make things more complicated for no good reason.

[lilyball]

@Aatch Agreed. Furthermore, all current FFI bindings can be created pretty easily by looking purely at the types involved in the C declaration. This absolutely is not the case with a non-nullable *T vs Option<*T>. The only way to know which type is correct is to read documentation, assuming the documentation even bothers to define behavior surrounding NULL, or even exists or is correct. And besides the gigantic headache this causes for deciding which types to use, it also completely breaks any ability to use automated FFI generation (e.g. rust-bindgen), because the automation tool can't possibly know whether it should be using *T or Option<*T>.

[huonw]

@kballard fwiw, GCC and clang have custom nonnull and returns_nonnull attributes for specifying that certain arguments are not null.