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

[Dmitry Olshansky]

11/30/2012 3:31 AM, 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.

And what you'd expect 't' to be then? And why such code is useful 
anyway? The only sane way I see is to make it an explicit call of 0-arg 
constructor then one can safely assume:
1. t is of type T
2. t is properly constructed and not some invalid state like T.init may be

Currently with opCall it could be anything otherwise it ends up T.init 
or compiler error if T is a built-in type.


> 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.

Why in the nine hells we have static opCall to begin with?
Probably to workaround 0-argument ctor situation. I haven't seen a 
better or at least sensible use case. Yet it has great potential for abuse.

(and the fact that compiler picks opCall first (static or not) instead 
of constructor doesn't help matters much)


-- 
Dmitry Olshansky