On Sunday 19 December 2010 18:13:54 Nick Voronin wrote: > On Sun, 19 Dec 2010 17:26:20 -0800 > > Jonathan M Davis <jmdavisp...@gmx.com> wrote: > > On Sunday 19 December 2010 16:50:34 Nick Voronin wrote: > > > On Sun, 19 Dec 2010 14:38:17 -0800 > > > > > > Jonathan M Davis <jmdavisp...@gmx.com> wrote: > > > > On Sunday 19 December 2010 14:26:19 bearophile wrote: > > > > > Jonathan M Davis: > > > > > > There will be a library solution to do it, but again, it's > > > > > > unsafe. > > > > > > > > > > It can be safer if the compiler gives some help. For me it's one of > > > > > the important unfinished parts of D. > > > > > > > > Whereas, I would argue that it's completely unnecessary. structs and > > > > classes serve different purposes. There is no need for scoped > > > > classes. They may perodically be useful, but on the whole, they're > > > > completely unnecessary. > > > > > > How do you define a need for scoped classes? > > > > > > I see two aspects there: first is having destructor called at known > > > point rather than arbitrarily, second is performance. > > > > > > It looks perfectly reasonable for me to want to have first. Do you know > > > why things which makes program act more deterministic are shunned from > > > D? Does it really add so much to safety that it is worth reducing > > > programmer's control? > > > > Then use a struct. > > Here is where we diverge. Choosing struct vs class on criteria of their > placement makes no sense to me. Difference in default placement hardly > matters at all, you can perfectly put structs in heap or in static segment > yet still maintain same properties. It's those properties which matter > when I choose one or another, not where it will reside in particular part > of program. > > > That's one of the reasons that they exist. And if you > > _really_ want to make sure that a class' destructor gets run, you can > > always use clear() (which is arguably an abomination in its own right). > > This is what I don't understand. Fine. structs are meant for stack, class > for heap. Conceptually, anyway. Still there will be ways to put class on > stack and struct in heap. And there is(will be) clear(). Now I do see > benefit of scope storage. It looks clean, it is supported by compiler > meaning reasonable level of protection against misuse, it is extremely > effective. What are benefits of _not having_ it?
Except that the compiler _can't_ protect against misuse. That's one of the main reasons that it's going away as part of the language. Structs are intended to their lifetime be the same as their scope. The lifetime for classes, on the other hand, is essentially as long as the program is running (though the garbage collector can obviously collect them in cases where they aren't used anymore). By trying to force a reference type to have a scoped lifetime, you're going against how they work, and it's just asking for trouble. Yes, it _can_ be done, but no, it _can't_ be done safely. As I understand it, Andrei isn't even entirely happy that clear() exists. I believe that pretty much the only reason that it exists is because there are cases where classes hold resources and you want to make sure that they get released rather than waiting for the object to get destroyed at some indeterminate point in the future. But really, the garbage collected heap is supposed to be managed by the garbage collector. And with scope, you're trying to take something that's designed to live on the garbage collected heap and put it on the stack. You're taking something that is designed to be used in one type of storage and using it in another. It's going to cause problems. C++ has a number of issues pricely because it allows classes to live on both the stack and the heap. By separating types that live on the stack from those that live on the heap, you avoid those problems. And actually, the fact that structs can live in the heap in D can be problematic, as evidenced by the bugs relating to destructors for structs on the heap. Not only do their destructors not get run, it's questionable whether the language will _ever_ be such that the destructors of structs on the heap will be run. The result is that in many cases, structs should either be designed to be on the stack or on the heap. D was designed so that classes live on the heap, and that's the way it works. Putting them on the stack is going against how classes are intended to work, and it's asking for trouble. - Jonathan M Davis
