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

[Andrei Alexandrescu]

On 10/11/12 9:52 AM, deadalnix wrote:
> Le 11/10/2012 14:19, Andrei Alexandrescu a écrit :
> 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 ?

Here I meant a named temporary, such as e.g. a pivot in quicksort.

>> 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.

One point I was making is that even with a default constructor, the 
definition and existence of .init pops all over the place, like a bubble 
in the carpet. I think it is a good engineering decision to simply make 
it the default state.

>> 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.

It doesn't disappear - it manifests itself in a different way 
(complexity in the language definition).

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

I agree heaps with required allocated state are unpleasant to deal with 
in the current design.

My overall point, which is worth repeating, is not that these problems 
are insurmountable. Instead, we're looking at different choices with 
distinct tradeoffs. There's no solution with all pluses.


Andrei