[foota]

This is a bizarre take to me, what do you want to do with classes that aren't supported by structs and traits? Imo the usability issues with rust arise from the borrow checker and associated complexity + restrictions on patterns, so I'm surprised that you're citing macros and classes.

[AnimalMuppet]

Access control.

Here's a struct that maintains an invariant - say, that field a is less than field b. That invariant should be set when it is created.

You find a bug where a is greater than b. Where is the bug? With a struct, it can be anywhere in the code - any line that touches the struct. But with a (well designed) class, a and b are private, and so you only have to look at lines of code within the class. The surface area where the bug can be is much smaller.

The bigger the code base and the more well-used the class is, the more this matters.

[kibwen]

Rust has privacy and encapsulation just fine. More than that, Rust's entire safety story is built on these mechanisms; being unable to (safely) access private fields outside of the module in which they were defined is load-bearing when it comes to safely encapsulating unsafe code.

[joshmarinacci]

You can do exactly this in rust using non public fields and accessor methods.

[tialaramex]

I think the large C++ or Java shaped hole in your understanding is simply that you think "class" means encapsulated and "struct" means Plain Old Data and in Rust that's not what it means.

Take std::os::fs::OwnedFd the file descriptor. In fact of course this struct is literally just a C-style integer inside, it's the same size in memory, representationally they're identical. But, it's encapsulated, so it gets to enforce the fact that file descriptors are never -1 by definition, and since it is encapsulated it gets to refuse to participate in arithmetic, and to call close when we throw away the file descriptor, and so on. It's a huge improvement.

[foota]

Ah, that makes some sense, although some reading says that struct member visibility is by default the module, which is a file if you don't do anything. If you wanted you could probably just wrap all the structs you want to be protected inside a module per file? It is a bit annoying though. I guess the issue here is that in rust struct fields need to be accessed for trait implementations. It wouldn't be backwards compatible obviously, but I wonder if they could have tightened that so that by default only trait implementations for a struct can access that structs members?

[3836293648]

Rust has exactly that. The difference is that rust considers the scope of private access te be the entire file it's defined in, not just its methods.

[kibwen]

Just the module the struct is defined in, not the file. Easy mistake to make, given that a file is implicitly its own module, but you can create submodules within a file with the `mod` keyword.

[3836293648]

I thought it crossed into submodules as well, making it the entire file?

[array_key_first]

Rust has access control, and rust has better mutability and reference control. Many languages like C# and Java let you take references willy nilly and do almost whatever you want.

[Dr_Emann]

Rust has access control. Fields are private by default.

[the__alchemist]

I'm confused too! When I write Python, I do it in a similar style as rust, but knowing the classes and enums are sloppier than rust's; regarding mutation for example.