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

[Jonathan M Davis]

On Thursday, November 29, 2012 20:27:32 Dmitry Olshansky wrote:
> 11/29/2012 7:24 AM, Walter Bright пишет:
> > On 11/29/2012 4:47 AM, monarch_dodra wrote:
> >> On Sunday, 25 November 2012 at 16:47:08 UTC, Dmitry Olshansky wrote:
> >>> Thoughts?
> >> 
> >> I don't know about "killing" T(), but I think there *needs* to be an
> >> (easy) mechanism to declare ***and*** run-time initialize an object, in
> >> a single and comprehensive line.
> >> 
> >> I had proposed something 2 months ago here:
> >> http://forum.dlang.org/thread/bvuquzwfykiytdwsqkky@forum.dlang.org
> >> 
> >> The proposal wasn't perfect, but still. We need to figure something
> >> out...
> > 
> > The original idea is that there should be *no such thing* as default
> > construction of a struct as being anything other than T.init. The
> > default construction of a struct should be a compile time creature, not
> > a runtime one.
> 
> Okay let it be. I'm not against having a defined blank default
> constructed object.
> 
> Just don't make T() mean it, please!

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.

- Jonathan M Davis