Should we have a way to perform C++ default initialization?

[zygoloid]

The testcase where I encountered this involves an explicit default constructor:

import Cpp inline '''
struct A {
    explicit A();
    A(const A&) = delete;
};
''';
var a: Cpp.A = ();

Currently we reject this, with a confusing error:

<source>:7:1: error: attempt to use a deleted function
    7 | var a: Cpp.A = ();
      | ^
<source>:4:5: note: 'A' has been explicitly marked deleted here
    4 |     A(const A&) = delete;
      |     ^

<source>:7:1: error: cannot implicitly convert expression of type `()` to `Cpp.A`
var a: Cpp.A = ();
^~~~~~~~~~~~
<source>:7:1: note: type `()` does not implement interface `Core.ImplicitAs(Cpp.A)`
var a: Cpp.A = ();
^~~~~~~~~~~~

The reason we reject is because C++ copy-initialization from {} is invalid because it would use an explicit constructor.

However, this leaves us with no easy way to provide initialization with the same semantics as C++'s

A a;

... which does permit calling an explicit default constructor. Should we have an ergonomic way to do that? Should the conversion from () do that?

[chandlerc]

Initial thoughts:

I think Carbon types should have a way to make var x: C; work, and leave x initialized fully.

And I'd be comfortable opting C++ class types with (explicit) default constructors into that.

[zygoloid]

Expanding on that idea a little, we could add an interface along the lines of:

interface Core.Default { fn Op() -> Self; }

that describes default initialization to a non-unformed state.

The rule from #257 and #5913 that the absence of an initializer puts the type into an unformed state would change as follows:

If an object has no initializer (var x: T;), then:

• If T impls Core.Default, the initializer is (T as Core.Default).Op() and the object is not unformed.
• Otherwise, if T impls Core.UnformedInit, the initializer is (T as Core.UnformedInit).Op() and the object is unformed.
• Otherwise, error. (We could allow this so long as there's no control flow convergence between paths where the variable is initialized and uninitialized if we wanted, but I don't think the current proposals do that.)

We'll need to work out how this affects the case where T is not constrained to be Core.Default in a generic. There may be cases where we need to conservatively perform an unformedness check but then later find that T doesn't actually use an unformed state.