Open JohelEGP opened 5 years ago
This should go through L(E)WG to form a policy opinion; maybe they want to deprecate make_pair
.
This doesn't seem editorial.
I don't see that as encouragement to use the function, just a statement of fact, andstd::make_pair
doesn't behave exactly the same as CTAD anyway.
and
std::make_pair
doesn't behave exactly the same as CTAD anyway.
Well, that's unfortunate. It's true that pair
's deduction guide doesn't use unwrap_ref_decay_t
. It's still not too late to make them consistent to ease transition in case of deprecating Actually not, CTAD is a C++17 feature, so transition seems hard without tools.make_pair
.
You assume making them behave the same is desirable. The different behaviour is intentional, not an oversight.
This is one of the many clean-up papers I have half written that never finishes in time for any mailing deadline. If anyone else thinks this is worth pursuing, I will try to focus and finish for the pre-Kona 2019 mailing. This affects use of both make_pair and maketuple, and we should choose between CTAD and make* precisely to indicate whether or not unwrap_ref_decay behavior is expected.
See https://wg21.link/pairs.general#1.sentence-2: "[...] The library also provides a matching function template to simplify their construction [...]"