`<future>`: `promise` default constructs the value type

[eiband]

Describe the bug
The value type T of a promise<T> is default constructed when the promise is constructed, which is surprising. I am not sure what the requirements of the standard are. The current implementation requires T to be default constructible and assignable. It is possible to implement promise with none of these two requirements.

Command-line test case

C:\Temp>type repro.cpp
#include <future>
#include <iostream>

struct test
{
  test()
    : result_{-1}
  {
    std::cout << "Default constructor" << std::endl;
  }

  explicit test(int i)
    : result_{i}
  {
  }

  int result() const
  {
    return result_;
  }

private:
  int result_;
};

int main()
{
  std::promise<test> prm;
  std::future<test> fut = prm.get_future();

  prm.set_value(test{0});

  return fut.get().result();
}

C:\Temp>cl /EHsc /W4 /WX .\repro.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30139 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

repro.cpp
Microsoft (R) Incremental Linker Version 14.29.30139.0
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:repro.exe
repro.obj

C:\Temp>.\repro.exe
Default constructor

Expected behavior
The line "Default constructor" should not be printed. Moreover, replacing the default constructor test() by

test() = delete;
test(const test&) = default;
test& operator=(const test&) = delete;

should still compile.

STL version
Microsoft Visual Studio Professional 2019
Version 16.11.9

vNext note: Resolving this issue will require breaking binary compatibility. We won't be able to accept pull requests for this issue until the vNext branch is available. See #169 for more information.

[cpplearner]

I think fixing this issue will need to break ABI. (See #169)

Note that <future> has a comment which is likely related to this:

STL/stl/inc/future

Line 197 in 86e22c3

// TRANSITION: _Associated_state ctor assumes _Ty is default constructible

[eiband]

I noticed this behavior when the default constructor of the value type T threw an exception, which occurred in a unit test.

[StephanTLavavej]

Yep, this is a known issue, that we've been treating as unfixable without breaking ABI (thanks Casey Carter (@CaseyCarter) for labeling it). We talked about this at the weekly maintainer meeting, and Casey Carter (@CaseyCarter) noticed that this resembles #2296, which was a similar issue of code failing to compile. We were able to fix that while preserving bincompat, by restricting the fix to affect only those cases that wouldn't compile (so there are no mix-and-match issues). In theory, the same approach could work here, although I believe more codepaths would need to be changed (array<T, 0> needed very small changes). Removing the vNext label accordingly.

[invertego]

Stephan T. Lavavej (@StephanTLavavej) I do not believe this bug has been fully fixed. The cited PR (#2568) fixed compile errors for non-default constructible types (which is nice!) but default constructible types are still being default constructed and moreover burdened with the additional requirement of being assignable.

Based on the discussion above, it sounds as though fixing the default constructible case would be considered ABI breaking, but it still seems this should be tracked somewhere, and since this issue was originally created specifically about default constructible types, wouldn't it make sense to reopen?

[CaseyCarter]

Good point: We closed this as if it were "future can't hold non-default-constructible types", which a great many folks have complained about loudly over the years. But there's also a "future incorrectly default-constructs a default-constructible contained value at construction time" bug here which has been less troublesome, but is just as non-conforming.

There's also the consequence that promise.set_value assigns to a default-constructed value when it should be constructing, but that's #1190 so we don't need to incorporate it here.