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

[Dmitry Olshansky]

12/1/2012 1:38 AM, Jonathan M Davis пишет:
> On Friday, November 30, 2012 23:34:04 Dmitry Olshansky wrote:
>> 11/30/2012 3:31 AM, Jonathan M Davis пишет:
>>> 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.
>
> If
>
> auto t = T();
>
> works then you don't have to care whether the type has a static opCall or not.
> You get the most valid default-constructed object that there is (or at least,
> the closest thing that there is to a default-constructed object). If that's
> init, then it's init. If it's static opCall, then it's static opCall. I don't
> want to have to care which it is. Also, if I see
>
> T t;
>
> I'm likely to think that was supposed to be initialized, but the programmer
> forgot, whereas with
>
Then I'd say
T t = T.init;
for when you want explicitness.

Other then this I've come to rely on
T t;
being default constructed and not rising an eyebrow.

It's only in context such as these 3 lines :
T x = blah;
U y = bleh;
W w;

That I'd think w == T.init might be unintended.

> auto t = T();
>
> it's clear that that it was intended to be initialized to whatever T() is (be
> it T.init or the result of a static opCall), and it's clear that the
> programmer didn't forget to initialize it.

Either way my final proposal doesn't remove it. In short it goes as follows:

- allow 0-arg constructors for consistency and cross-cutting issues 
(like all default args ctor)
- use a default one (as is done with per-field constructors) if none or 
user defined match. The default will blit object with T.init.

It'd let static opCall be there as is. It will just put them in the same 
overload set as constructors.

-- 
Dmitry Olshansky