Time to kill T() as (sometimes) working T.init alias ?

[deadalnix]

On Thursday, 29 November 2012 at 23:31:54 UTC, Jonathan M Davis 
wrote:
> I'm all for T() meaning T.init if T doesn't have a static 
> opCall, but T()
> shouldn't be guaranteed to be T.init. I'd very much like to see 
> code like
>
> auto t = T();
>
> to continue to work regardless of whether T has a static opCall 
> or not. But it
> should be able to have a static opCall, and T() should work if 
> it doesn't have
> one. Assuming that T() means T.init makes no sense.
>

opCall is really a poor workaround because it doesn't allow new, 
it is inconsistent with other constructors and is unexpected by 
the user.

How much opCall has spread tells more about how parameterless 
constructor is needed than something else.