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

[Nick Treleaven]

On 29/11/2012 16:27, Dmitry Olshansky wrote:
> 11/29/2012 7:24 AM, Walter Bright пишет:
>> 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!
>
> There are a 0-argument constructor or rather a run-time construction
> that need no arguments. Examples are auto-seeded PRNG, empty containers,
> digest that typically use default initial vector etc.
>
> Plenty of things. If classes have it why shouldn't structs have one as
> well? Is there any reason to introduce this discrepancy?
>
> The sudden change of user-defined run-time construction to a biltblit a
> T.init mask once number of arguments is 0 is a nasty surprise and is a
> high irregularity in the language.
>
> The unwary may hit a brick wall quite suddenly. Even better example are
> constructors with all default args:
>
> //simplified
> struct A{
>      int[] values;
>      this(int size=10) //default size...
>      {
>          values = new int[size];
>      }
> //...
> }
>
> A a = A(20); //okay
> A b = A(); //try to pick defaults...
> assert(b.values is null); // passes - WTF?
>
>> Any methods or workarounds to try and make T() produce something
>> different from T.init is bad D practice.  The compiler tries to
>> statically head them off, but probably should do a better job of that.
>
> Why do we have to use T() syntax for this? It blocks 0-argument
> constructor & ones with all defaults.
>
> Default construction is done either way unless avoided with =void and
> there is always a T.init. I've spent quite some breath trying to show
> how T() is unhelpful in any case one needs a default constructed object.

Totally agree with all this. I can't understand why T() should 'default 
construct' T - it's not default anything if you explicitly type T(). 
static opCall is an ugly workaround especially in generic wrapper code. 
Not allowing 0-argument constructors is unintuitive. I have several 
times tried reading explanations of why it's like this to no avail. If 
you are allowed to call other runtime constructors, why not zero-arg ones?

struct A{...}
A a; // fine, default construct a
A a = A(); // why does this mean the same thing???

I wish we could deprecate the second syntax as we really need to 
repurpose it.