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.
