Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GB-087 20.2.6 [obj.lifetime] std::start_lifetime_as API is broken and inconsistent for arrays #458

Closed
wg21bot opened this issue Oct 24, 2022 · 5 comments
Labels
LEWG Library Evolution rejected No consensus for a change. size - medium
Milestone

Comments

@wg21bot
Copy link
Collaborator

wg21bot commented Oct 24, 2022

The API of std::start_lifetime_as is broken and inconsistent for arrays.

First, is inconsistent with other APIs in the standard library that create objects and accept both array and non-array types, such as std::make_shared and std::make_unique. These have a version for non-array types, a version for array types of known bound, and a version for array types of unknown bound, respectively, all with the same name.

Further, the current naming is also inconsistent with itself in multiple ways: the overloads that work for arrays of unknown bound have the suffix _array in the name, but the overloads that work for arrays of known bound do not. This does not make any sense and is highly confusing for users.

In the same way that the naming is inconsistent with existing standard APIs and also with itself, the template parameters are also inconsistent. For std::start_lifetime_as, when used with an array type U[N] of known bound, the template argument that the user needs to provide is the type U[N] of the object being created (for example, std::start_lifetime_as<int[16]>), while for std::start_lifetime_as_array, the template argument is not the type U[] of the object being created, but the type of its elements U.

Finally, the overloads for arrays of unknown bound (the ones with the suffix _array) return a pointer to the first element of the array, while the overloads without the suffix _array, when used with an array type of known bound, return a pointer to the array itself. In other words, a call to std::start_lifetime_as_array<int>(p, 16) will return an int*, but at the same time a call to std::start_lifetime_as<int[16]>(p) will return an int(*)[16], which makes creating and using arrays with this facility very awkward and unintuitive.

Adopt the changes proposed in P2679R0.

@wg21bot wg21bot added the LEWG Library Evolution label Oct 24, 2022
@wg21bot wg21bot added this to the CD C++23 milestone Oct 24, 2022
@brycelelbach
Copy link

Proposed resolution is P2679 cplusplus/papers#1345

@jensmaurer jensmaurer changed the title GB 20.2.6 [obj.lifetime] std::start_lifetime_as API is broken and inconsistent for arrays GB-087 20.2.6 [obj.lifetime] std::start_lifetime_as API is broken and inconsistent for arrays Nov 3, 2022
@FabioFracassi
Copy link
Collaborator

TODO: Bryce
Add polls and notes

@FabioFracassi FabioFracassi added CWG Core LWG Library and removed LEWG Library Evolution labels Nov 9, 2022
@nliber
Copy link

nliber commented Nov 10, 2022

POLL: We want to reject the proposed resolution of GB-087.

Strongly Favor Weakly Favor Neutral Weakly Against Strongly Against
11 6 3 0 0

Attendance: 20 + 3

# of Authors: 1

Author Position: SF

Outcome: Strong consensus

@brycelelbach
Copy link

2022-11 Library Evolution Electronic Poll Outcomes

Poll 1.12: Reject C++23 National Body comment GB-087 start_lifetime_as Is Broken And Inconsistent For Arrays as per [P2679R1] Fixing start_lifetime_as For Arrays .

Strongly Favor Weakly Favor Neutral Weakly Against Strongly Against
14 3 1 1 0

Outcome: Consensus in favor.

@jensmaurer
Copy link
Member

Rejected. There was no consensus for a change.

@jensmaurer jensmaurer added the rejected No consensus for a change. label Jan 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
LEWG Library Evolution rejected No consensus for a change. size - medium
Projects
None yet
Development

No branches or pull requests

5 participants