No null for Rust

Say I created an application using Rust. If there is no null, what is happening with memory in terms of all of the empty cell into which data has not been entered and yet variables are assigned?

Cell?

This is what is known as uninitialized memory and in general cannot happen in safe Rust.
Edit: By safe Rust, I mean what you can access without using unsafe and can access at all. You can always have a MaybeUninit::uninit(), but you can't access it meaningfully without unsafe.

1 Like

You can have uninitialized variables in safe Rust, you just can't use them. For example, this code would not compile:

fn main() {
    let foo;
    
    if condition() {
        foo = 1;
    }
    
    println!("{}", foo);
}
error[E0381]: borrow of possibly-uninitialized variable: `foo`
 --> src/main.rs:8:20
  |
8 |     println!("{}", foo);
  |                    ^^^ use of possibly-uninitialized `foo`
  |
  = note: this error originates in the macro `$crate::format_args_nl` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0381`.
error: could not compile `playground` due to previous error

Whereas this code would, as the compiler knows you initialize the variable in all branches:

fn main() {
    let foo;
    
    if condition() {
        foo = 1;
    } else {
        foo = 0;
    }
    
    println!("{}", foo);
}
5 Likes

Every application takes input from a user, say MS excel for example. Each new worksheet as a number of empty cells. So, If I were to create a spreadsheet using Rust, there would be a bunch of empty cells into which the user would input data of some sort. Would they be variables with no assigned values? I don't understand how this would relate to the no-null-for-Rust concept.

When you want a variable that may or may not contain a value, you use the Option type, which can either be Some(a_value) or None. You cannot get a_value out of the Option without being explicit about what you want to happen in the case where it's None and there is no value.

3 Likes

You would represent the value as Option<CellContent>. You initialize them as None and replace them with Some(value) when you have a value.

2 Likes

If you were to create a spreadsheet (programmatically or in Excel) the empty cells would not exist. You wouldn't allocate for something that isn't there. You'd just keep a index of what cells are used. Not of the unused ones.

3 Likes

The concept that Rust doesn’t have “null” is not about the fact that “null (pointers)” doesn’t exists at all in Rust, and more about the fact that Rust does rule out null by default.

In many other languages, you have that

  • every pointer type always can be null
  • it is common to very implicitly assume that a pointer you work with is not null, and wrong assumptions lead to crashes or undefined behavior
  • variable initialization is not tracked, but instead null serves as the default implicit value that most pointer-type variables/fields start out with

whereas in Rust

  • no pointer type can be null (except for unsafe raw pointers)
  • variables start out truly uninitialized, and initialization is tracked (so you can’t use uninitialized variables), but you have to initialize everything (semi-)explicitly, so there isn’t a bunch of implicit zeroes or nulls appearing everywhere (except perhaps when you use derived Default implementations, though arguably, there’s still some level of explicitness around in this case)
  • you do have Option<…> which serves all purposes that null does if you need it. You can thus opt-in to null-like functionality.
    • Option<…> is more general, it can be used with pointer-types and other types; for pointer-types (which can’t be null themselves on their own) there’s an optimization that None will actually be represented efficiently as a null pointer
    • Distinguishing Option<Foo> from Foo means that you only can get None values if you opt-in to it. And Option<Foo> has a different API from a Foo itself, leading to the next point that…
  • …using Rust’s null-equivalent, Option<…>, every time where you assume a value is not None is very explicit, you’re forced to always either handle the possibility of a None case, or explicitly use something like .unwrap() to assert “non-null-ness” (in which case, you’re still guaranteed to get a crash [via panic] and no undefined behavior)
5 Likes

You are assuming that a new, empty, worksheet is some huge 2 dimensional array in memory, with thousands of rows and columns, waiting for the user to fill with data.

That is almost certainly not true. That would mean that a new, empty, sheet would instantly consume all the memory in your machine. What you see on screen as a huge grid you can scroll endlessly up and down, left and right, is just a graphical illusion. There is no data behind it anywhere. Initialised or "null" or whatever.

Rather, memory is allocated for data as it is entered. In some cunning "sparse array" data structure. Don't ask I have no idea how, but I have a notion of how it could be done.

So, no, there is no need for "null" as there is no memory allocated that could contain nothing.

7 Likes

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.