search

cplusplus / draft

C++ standards drafts
http://www.open-std.org/jtc1/sc22/wg21/
5.69k stars 748 forks source link

[pairs.general] Don't encourage use of `make_pair` since we have CTAD #2492

Open JohelEGP opened 5 years ago

JohelEGP commented 5 years ago

See https://wg21.link/pairs.general#1.sentence-2: "[...] The library also provides a matching function template to simplify their construction [...]"

jensmaurer commented 5 years ago

This should go through L(E)WG to form a policy opinion; maybe they want to deprecate make_pair.

jwakely commented 5 years ago

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.

JohelEGP commented 5 years ago

andstd::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 make_pair. Actually not, CTAD is a C++17 feature, so transition seems hard without tools.

jwakely commented 5 years ago

You assume making them behave the same is desirable. The different behaviour is intentional, not an oversight.

AlisdairM commented 5 years ago

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.