What is the case against a struct post-blit default constructor?

[deadalnix]

Le 11/10/2012 14:19, Andrei Alexandrescu a écrit :
>
> We could (after all, C++ does it). There are a few disadvantages to
> doing so, however.
>
> 1. Defining static data is more difficult. Currently, all static data is
> statically-initialized. With default constructors, we'd need to define
> the pre-construction state of such objects anyway, and then change the
> compiler to call constructors prior to main(). I find the current design
> simpler and easier to use.
>

CTFE is probably the answer here.

> 2. Creating a temporary object cannot be anymore assumed to be a O(1),
> no-resources-allocated deal. Instead, generic code must conservatively
> assume that objects are always arbitrarily expensive to create. That
> makes some generic functions more difficult to implement.
>

Temporary object are used to store temporary state coming from some 
computation. In this case, the computation create the complexity, the 
object isn't created via default constructor.

Or have you a use case in mind I don't think of ?

> 3. Two-phase object destruction (releasing state and then deallocating
> memory), which is useful, is made more difficult by default
> constructors. Essentially the .init "pre-default-constructor" state
> intervenes in all such cases and makes it more difficult for language
> users to define and understand object states.
>

This one is made worse by the current state. You have to assume 
everywhere that your struct can be .init

Even when it doesn't make any sense. RefCounted is a pathologic case of 
that.

> 4. Same as above applies to an object post a move operation. What state
> is the object left after move? C++'s approach to this, forced by the
> existence of default constructors and other historical artifacts, has a
> conservative approach that I consider inferior to D's: the state of
> moved-from object is decided by the library, there's often unnecessary
> copying, and is essentially unspecified except that "it's valid" so the
> moved-from object can continue to be used. This is in effect a back-door
> introduction of a "no-resources-allocated" state for objects, which is
> what default constructors so hard tried to avoid in the first place.
>

If we give struct a giveaway state (where the struct cannot be used 
unless it is reinitilized to a correct value) this problem disappear.

Except in the case 5. (and heap allocated struct in general), that in 
fact seems to me the major issue.

> 5. There are a few minor issues such as correct array creation etc. but
> I don't consider them decisive.
>