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

[Dmitry Olshansky]

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!

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.

-- 
Dmitry Olshansky