[steveklabnik]

Rust has From/Into and TryFrom/TryInto that do the same thing, as far as I can tell. It's not clear to me what the differences are, maybe someone else in this thread will know. :)

> Why not hide it a bit by letting the implicit copy to happen to simpler structures ?

This is the Copy trait.

> Why no love for inheritance

There are a variety of reasons, but one interesting one is that inheritance and strong type inference have issues, and we have very strong type inference. Beyond that, there are various other reasons, but what it really comes down to is that there's just not a ton of pressure to actually implement it; it's not enough of an impediment for Rust users to justify adding it. Most requests come from people who do not write Rust, and once people get into Rust and how it works, they don't seem to need it much anymore.

This is of course very general and there are some people who love it and want it badly anyway, but "some people exist who want this feature" is not enough to make it happen. Rust already has a lot of features, and some people say too many. We have to be careful here.

> Why no love for global/static variables ?

What does "love" mean? Rust absolutely supports these.

[option_greek]

Sorry for got to mention the 'mutable' part. So a mutable singleton variable that has to be marked with an unsafe keyword (and forces the functions that use to be marked as unsafe). The other day I was struggling to implement a singleton (for loading large data from disk) and finally decided to just pass it down the whole chain from the main method. May be I'm missing some easy pz way of doing this ?

[steveklabnik]

So yes, that is because it is unsafe, according to Rust's definition of safety. However, there are tools you can use to remove this.

First of all, I find that many people aren't using multiple threads, and therefore, what they want is a thread-local, not a static. For that, you can use https://doc.rust-lang.org/stable/std/macro.thread_local.html

If you do need a static, then there are libraries like https://docs.rs/lazy_static/1.4.0/lazy_static/ and https://crates.io/crates/once_cell to help too. We have talked about adding something like this to the standard library, but it hasn't landed yet. https://github.com/rust-lang/rust/issues/74465 is the tracking issue for when it does. The reason that we don't have this yet is that it is not super urgent, given that the libraries already exist.

Now, both of those give you immutable statics, but that's where interior mutability comes in. As you can see from the thread_local examples, you can use a RefCell there, and if your type is simple enough, maybe even regular Cell. For lazy_static or once_cell, you may want to use Mutex<T>, or RwLock<T>, or some other type. For simple integers, the various Atomic* types might be better, for example. The reason this isn't built in is exactly because there are so many options; people need all of these specifics, so we have to provide them, so there's no single built-in thing.

[brundolf]

Here's how you can do global mutable state in Rust:

  #[macro_use]
  extern crate lazy_static;

  use std::sync::Mutex;

  lazy_static! {
    static ref ARRAY: Mutex<Vec<u8>> = Mutex::new(vec![]);
  }

  fn do_a_call() {
    ARRAY.lock().unwrap().push(1);
  }

  fn main() {
    do_a_call();
    do_a_call();
    do_a_call();

    println!("called {}", ARRAY.lock().unwrap().len());
  }

I agree that this isn't the most ergonomic, but like most unergonomic things in Rust, there are reasons for it being so.

[steveklabnik]

(You'd probably replace the first two lines with "use lazy_static::lazy_static;" in today's Rust, that older style isn't as idiomatic.)

[shepmaster]

https://stackoverflow.com/q/27791532/155423