The fact that the solution is not to simply invoke the copy constructor, but to (portably!) write an ungodly mess that uses double-references, full noexcept(noexcept(repeat_of_body)) daisy-chaining,
std::forward(a function that doesn’t forward), and probably constexpr, and probably explicit(explicit(…)) daisy-chaining, and probably requires(requires(…)) daisy-chaining, and probably constinit, and probably structured bindings, and probably yet another form ofauto, and so on…, demonstrates the problem with C++.There’s a place for macros, and this example shows it is precisely it. I’d just write
MAKE_COPY(x).If you look at it… The answer is actually to invoke the copy constructor. They’re just complaining that, that can be unwieldy, then going on to say … “actually if you’re using C++17 this is all really easy just say auto(x) instead of writing your own copy constructor!”
It’s a lot of words (IMO) without that much substance.
The macro would be unnecessary complexity vs their pre-C++17 compatible copy function FWIW.
The other alternative here which is why I think this is kind of ridiculous is 9/10 you can just change the function you’re calling to pass a copy rather than passing a reference if that’s what you really want.
The other alternative here which is why I think this is kind of ridiculous is 9/10 you can just change the function you’re calling to pass a copy rather than passing a reference if that’s what you really want.
…That’s a pretty good point. Use the type system to work for you. If you want a value thing, just get it by-value. No need for macros, no need for wildcard ampersands, no need for
constexpr constinit consteval static inline noexcept(noexcept(...)) requires(requires(...)) explicit(explicit(...)) { body } -> decltype(body).
