GOOG is a big company, and not everyone handles this the same way. At least some teams are doing what the sibling mentioned: A static factory-like method that returns a discriminated union of either T or an error type. It is conceptually similar to std::variant<T, std::error_condition>, but syntactically optimized for this use case.

Google has StatusOr<T> for this purpose: https://github.com/google/protobuf/blob/master/src/google/pr...

Yep, that's the one.

I tried to imagine the error message given by this template when something is written wrong. Just had a vision of horror.

So how do you protect yourself against inadvertently passing around uninitialized objects?

Exactly.

Objects with an artificial invalid state are an antipattern in idiomatic c++.

Cautioun.

And the destructor has to check for initialization before cleanup.

Am I the only one that finds it ironic that you have a typo in the word "Caution"?

I'd be very suspicious of any failure avoidance system that relies on "user caution".

But all failure avoidance systems rely on user caution. Error return values have to be checked. Exceptions have to be caught and handled (correctly). RAII has to be done everywhere a resource is allocated.

Now, true, some of these impose lesser burdens than others. Arguably, RAII imposes the least - but not zero. And if you forget with any resource, for that resource you are vulnerable.

That we can't make things perfect is no reason not to make things better.

And ultimately it should be possible to enforce that all resources are managed, because ultimately all resource interfaces have to be provided by the language runtime. To a certain extent enforcing user-defined invariants is always a matter of taste, but at the same time a language that makes it easy makes people a lot better at it.

You'll get a run time error.

Maybe. Or maybe you'll get an invisible resource leak, or silent data corruption, or an RCE vulnerability.

Well I don't know about that. If you have a datatype whose constructors can't throw, it should still assert at run time about its state that it's been initialized. Like, you have to actually do that, of course. So there's more surface area for mistakes inside the object, but from the outside of the object, which is what I think this sub-thread is talking about, they get caught at run time.

It shouldn't have to be assertions though - you should make it correct by, well, construction. When the fields are RAII the constructor can just initialize them. If your class has different possible states and flags it's usually correct to promote the different states to differnt types (subclasses).

I don't think we're disagreeing about anything. The scope of my comment is in reference to "So how do you protect yourself against inadvertently passing around uninitialized objects?" The answer is, with a run-time error.