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

[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

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.

> > But it
> > should be able to have a static opCall, and T() should work if it doesn't
> > have one. Assuming that T() means T.init makes no sense.
> 
> Why in the nine hells we have static opCall to begin with?
> Probably to workaround 0-argument ctor situation. I haven't seen a
> better or at least sensible use case. Yet it has great potential for abuse.
> 
> (and the fact that compiler picks opCall first (static or not) instead
> of constructor doesn't help matters much)

I don't know why we have static opCall, but it's used heavily for no-arg 
constructors, and it's extremely useful to be able to have those.

Interestingly enough though, if you were to give all of your class static 
opCalls, it would become possible to construct classes as if they were structs 
and not care which you're dealing with (similar to what std.container.make 
tries to do). I don't know that that's necessarily a good idea, but it's at 
least another potentially useful way to use static opCall other than providing 
no-arg constructors to structs.

- Jonathan M Davis