[tialaramex]

Object mutability isn't relevant here. A Date type which is mutable can ensure that all mutations are valid, it just can't do so while retaining this clumsy "LOL I'm just a D-M-Y tuple" API.

We can see immediately that your type is broken because it allows us to directly set the date to February 31st, there's no concurrency bug needed, the type was always defective.

[gf000]

  void setDate(int month, int day) {
    if (notValidDate(month, date)) { throw; }

    this.month = month; // atomic
    this.day = day // atomic
  }

Yet the whole function is not "atomic"/transactional/consistent, and two threads running simultaneously may surface the above error.

Of course it can ensure that it is consistent, C code can also just ensure that it is memory safe. This is just not an inherent property, and in general you will mess it up.

The only difference is that we can reliably solve memory safety issues (GC, Rusty's ownership model), but we have absolutely no way to solve concurrency issues in any model. The only solution is.. having a single thread.

[tialaramex]

But you were critiquing Rust's model, yet you've written C++ here. I agree it's perfectly easy to write the bug in C++.

In Rust this improved type doesn't have the defect, to call Rust's analogue of your setDate function you must have the exclusive mutable reference, which means there's no concurrency problem.

You have to do a whole lot of extra work to write the bug and why would you, just write what you meant and it behaves correctly.

[gf000]

It's called pseudo-code, and some extra attempt on your part to deliberately miss the point.

Give it another go at understanding what I'm saying, cheers!