What is going on here?

[Shachar Shemesh via Digitalmars-d]

On 07/03/15 07:09, Steven Schveighoffer wrote:

>> That's pretty horrible. So now I need to keep track of the
>> implementation of my members to figure out whether it is okay to skip
>> the destructor or not.
>
> Why does it matter? If the member is constructed, insert a
> scope(failure) destroy, otherwise don't.
The whole point of RAII is to prevent errors that happen when the 
programmer isn't as vigilant as she should be. RAII reduces the amount 
of vigilance required, thus eliminating errors before they happen.

What you are offering here is the precise opposite of that. Not only do 
I need to remember to add a scope after each initialization, I need to 
figure out whether my constructor throws, and whether any constructor 
I'm calling throws. That's an unrealistic level of work just so RAII can 
save me work.

> Or don't throw in the ctor and
> mark it nothrow, then you don't have to worry about it at all.
No. I also don't have to worry about using structs that did not mark 
their constructors nothrow, or, pretty much, anything 3rd part at all.

>
>> All of this from a language that claims to support RAII, which was
>> invented precisely so the programmer does not have to keep track of
>> those things.
>
> It would be nice if there is a way. D, unlike C++, does not separate
> construction of members from the code. This means the situation is not
> as easy to solve.
>
> But an interesting question -- when constructing a struct or class,
> isn't every member initialized with it's init value anyway? Why would
> calling dtor on that be bad?
Now, that I can live with. Define the language that the member contains 
the init value until replaced by the first assignment in the 
constructor. Also state that if the compiler feels confident in figuring 
out that the member will always be initialized by the constructor, it 
can leave out both init initialization and destruction until after 
actual initialization.

I think, as far as language standard goes, that is reasonable. It is 
something I can work with. The only performance penalty compared to 
current situation is in the exception path, which is slower anyways.

Shachar