DIP44: scope(class) and scope(struct)

[Ramon]

I don't want to be picky but I feel one shouldn't pack too much 
into one thing and in a way break the logic flow and possibly 
introduce limitations.

The basic rule is to clean up in the destructor what has been 
allocated/aquired in the constructor - and this shouldn't be 
interrupted but stay that way.
What you want to address, if I got it right (If not, I apologize 
for my interruption) is the problem of incoherent state, i.e. 
(relating to your example) to have res1 and res2 aquired but not 
res3.
In my (possibly strongly limited) understanding scope(failure) is 
the right approach.

Having a mechanism (as suggested) that also takes care of the 
dtor's job breaks the normal logic and might create new problems 
or limitations by implicitly putting a dtor job into a ctor 
mechanism.

What, for instance, if I aquire 10 resources in ctor and during 
normal programm execution cleanup 7 of them, so only some are 
left for dtor?


If scope(failure) does already work in ctor, just keep it that 
way. If not,HS Teoh's idea to make it work is great. But that 
about it. Don't add more functionality in it. Normal ctor/dtor 
working should be kept and so should scope(). Whatever user wants 
beyond that can be coded by him. Don't break major flow for some 
luxury (having scope in ctor isn't luxury, having it reach into 
dtor, too up to the point of making dtor superflous is).

scope is a brilliant feature. But I feel we shouldn't have it do 
"miracles", even less behind curtains.

In case what I said is just plain stupid and I should have shut 
up as newbie, I apologize and won't disturb any more.