Enjoy your combinatorial explosion of states.

It's not equivalent at all.

Could you elaborate? Rust manages pretty well without constructors and I'm nearly certain that it doesn't have any kind of combinatorial explosion of states. Same for ML-family languages.

See other parts of the thread.

That’s really not an issue, as pointed out in other parts of the thread.

Can you enforce at compile-time that only such a static factory can ever be used for creating the object in Rust? This is the whole point of constructors, they cannot not be used. Otherwise you're just one commit away of creating an object that will not respect the invariants - will you even remember to call this specific factory function in 6 months?

There are enough practices that handle this problem just fine in various ways. Like, make the function that should be used stand out in an obvious way.

If that is the whole point of constructors, it's the best argument why Rust does not have them. Programming is chock-full of "this must be called only by that or in this or that context..." and practically speaking, only a part of them can be handled by language objects and construct/deconstruct semantics.

Plus, C++ gives enough escape hatches to get not-constructed objects or to un-construct objects without them going out of scope. The "guarantees" provided by C++ that require a ton of baggage like ridiculous initializer lists or 17 different kinds of constructors (to the point where it's sometimes almost impossible to tell which will be called), or requiring an out-of-band mechanism (exceptions) to signal construction failure.... are simply not worth it in my book.

You get this by default for any object with non-public fields.

Sure, just make the fields of the struct private and you can make a public constructor:

https://doc.rust-lang.org/rust-by-example/mod/struct_visibil...

Yeah weird question because you can use the exact same style in C++.