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

[Nick Treleaven]

On 29/11/2012 12:10, Maxim Fomin wrote:
> On Thursday, 29 November 2012 at 10:41:46 UTC, Mehrdad wrote:
>> I'm just not understanding the whole "the default construction of a
>> struct should be a compile time creature, not a runtime one".
>>
>>
>>
>> Don't you have to initialize the struct with zero's either way?
>>
>> So either way, you're going to have to initialize it... so no perf
>> increase in any way. Why prevent the user from default-initializing it
>> the way he wants to?
>
> Every type has a CT-known default initializer, even classes have (null).
> If structures had a runtime one, this would break code (especially
> templates and CTFE) which relies on knowing something about constant
> default instance of a type at CT.
>
> extern bool foo();
>
> struct S
> {
>    int i;
>    this() {
>      i = foo() ? 1 : -1;
>    }
> }
> ---------
> S s;
> dosmth(s);
> ---------
> //somewhere in Phobos
>
> void dosmth(T) (T obj)
> {
>    T val; // is i 0, -1 or 1 ?
> }

I think s.i and val.i should be zero. S.this() should never be called 
implicitly IMO, but instead like this:

// runtime code
S s = S();

These two should always be equivalent, and compile-time evaluated:

S s;
S s = S.init;

If we actually need non-trivial compile-time 'default' constructors, 
they should have a different syntax:

// runtime ctors
this();
this(int x = 0);
this(T...)(T args);

// CT ctor (if actually needed)
default this(){...}

S.init would imply a call to the above CT constructor.