On 15/12/12 08:50,
stackm...@hotmail.com wrote:
> It has often occured to me that I have a function returning a
> std::unique_ptr. Naturally, I would expect this to work:|
> |
> ||
> |structfoo {};
>
> std::unique_ptr<foo>bar(boolbaz)
> {
> if(baz)
> return{};
>
> return{newfoo };
> }|
> The problem is the foo* constructor here, because it is explicit (for
> very good reasons). What I have to write instead is the following:
> ||
> ||returnstd::unique_ptr<foo>{newfoo };
> ||
> It's not much better with a make_unique facility.
>
> The same problem applies to std::tuple too.
> ||
> void foo(std::tuple<int, double, std::string>);
>
> foo({ 42, 3.14, "Hello, World" }); // error
> foo(|std::tuple<int, double, std::string>|{|42, 3.14, "Hello, World"
> |}); // works, but eww
> foo(make_tuple(|42, 3.14, "Hello, World"|)); // works, but i didn't use
> it for type deduction, which is against its intent
Concur. These two cases in particular (unique_ptr and tuple) have vexed
me on several occasions.
> I think the {}-syntax is already explicit enough, therefore it should
> allow calling explicit constructors without the type. Is there anything
> I have missed?
The most recent document I can find on this topic with rationale is
N2352
<
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2532.pdf>.
However, this appears to explicitly state that the above style of
construct should be valid. I guess something changed after that. Can
anyone point to a more recent document?
I think the only way to fix this without it being a breaking change is
to introduce another keyword to allow explicit constructor to opt back
in to copy-list-initialization. e.g.
explicit listinit unique_ptr(pointer p) noexcept;
This is moderately ugly, but I could live with it.
(Note that this is only not a breaking change at the language level. If
we change standard library constructors (which of course we must to
avoid the above issues) then we risk breaking code)
However, my preference would be to simply scrap the clause and allow all
constructors in copy-list-initialization. I have not yet seen a
compelling argument against this route.
In either case, I think that there would be very few breakages.
John Bytheway