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
.
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);
}
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.
You would represent the value as Option<CellContent>
. You initialize them as None
and replace them with Some(value)
when you have a value.
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.
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 thatnull
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 thatNone
will actually be represented efficiently as a null pointer - Distinguishing
Option<Foo>
fromFoo
means that you only can getNone
values if you opt-in to it. AndOption<Foo>
has a different API from aFoo
itself, leading to the next point that…
-
- …using Rust’s null-equivalent,
Option<…>
, every time where you assume a value is notNone
is very explicit, you’re forced to always either handle the possibility of aNone
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)
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.
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.