What is the case against a struct post-blit default constructor?

[monarch_dodra]

On Wednesday, 10 October 2012 at 09:48:27 UTC, Jonathan M Davis 
wrote:
>
> [SNIP]
>
> - Jonathan M Davis

After thinking about it, a lot, I think that would actually be 
the correct solution. I was an advocate of the "no-arg" 
constructor (not necessarily default), but I think it would end 
up being ambiguous in things like "emplace(&t)": "Do you want 
.init, or .__ctor()?"

This, I think makes sense:
T t; //T.init
T t = T(); //opCall

As for "new()", one can just two line it:
p = new T(); //T.init
p = T();     //opCall

It takes two lines, but it makes a perfect distinction between 
.init and T().

--------

But are you telling is that the "opCall trick" is now official 
sanctioned as the way of initializing things that may need 
initialization, even though no arguments are passed?

Can I roll it out in std.container? In RefCounted? In random? 
They are all "payload" structs, and they are in desperate need of 
some formal way to say:

"I want you initialized with your payloads and ready for use, but 
I have nothing to give you."