[cfe-dev] [bug?] list-initialization failures in a return statement

[Jim Porter]

On 8/21/2014 8:47 PM, Richard Smith wrote:
> If you'll excuse me making up terms, DefaultConstructible only requires
> that direct-default-initialization is valid, not that
> copy-default-list-initialization is valid. That's probably the bug in
> the standard; your type should probably not be considered to be
> DefaultConstructible.
>
> Here's a dumb workaround:
>
>    template<typename T> struct DirectInit {
>      T value{};
>      operator T&() & { return value; }
>      operator T&&() && { return value; }
>      // ...
>    };
>    template<typename T> DirectInit<T> make() { return {}; }
>
> ... but I'm somewhat wondering why you would have an explicit default
> constructor in the first place.

Well, in practice, *I'd* never want it, but I was trying to be as 
generic as possible, since this is part of a factory function for a test 
framework, and I'm not in control of the types in question.

Really, this is more of a curiosity for me at the moment, since I'm ok 
with saying "objects with explicit default-ctors can't be used as a test 
fixture" (and if I ever change my mind, I can easily write a 
specialization of the relevant code to avoid this). Still, it's a bit 
disheartening that the standard still has this edge-case in what I'd 
argue is a part of "perfect forwarding".

I'll write up a message about this and post it to the ISO discussion 
group just for the sake of completeness. Maybe it'll turn out to be an 
issue someone else has an interest in, but if not, I'm not terribly upset.

Anyway, thanks for the references to the relevant part of the standard.

- Jim