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

[Dmitry Olshansky]

11/25/2012 9:25 PM, Timon Gehr пишет:
> On 11/25/2012 05:47 PM, Dmitry Olshansky wrote:
>> After killing this ugly craft the suggestion is to, of course,
>> introduce 0-argument constructors.
>
> I think it should be done, but then it is even less clear how .init
> should work.

I suppose that T.init is the blank object, that is composed of 
respective initial values of its fields. Initial value is the one 
specified during declaration of a field or .init of its type.

You mean the more or less working @disable this();  ?
That might need extra consideration.

>
>>  static opCall can't prevent introduction of 0-arg constructor as the
>> compiler already has to disambiguate between the static opCall and the
>> ctor. (BTW which one wins?)
>
> It does not disambiguate.
>
> I think constructors and static opCall should just overload against each
> other,
+1
I can't think of anything more logical then to do just that.

>
> The current behaviour in case there are both opCall and constructors is
> to attempt to pick opCall in case the number of arguments is zero and
> the constructors otherwise.
>
>
>> ...
>>
>> Thoughts?
>>
>
> 1. is valid.
> 2./3. are examples of insufficient template constraints.
>

Agreed. The point of second however was mostly about built-ins not 
having this way of default construction. Thus T() is quite brittle in 
generic code (if the default construction is implied).


> If the suggestion is to get rid of the built-in struct 0-arg default
> constructor iff the user provides his own constructors, as is done with
> the more than 0-arg default constructors, then I fully agree.

Indeed, I haven't thought of automatically provided per-field 
constructors. I like your suggestion to do the same with 0-arg ones - 
provided automatic one returning T.init. Should be more consistent and 
even backwards compatible I guess.

-- 
Dmitry Olshansky