Jeremie Pelletier wrote: > downs wrote: >> Don wrote: >>> downs wrote: >>>> Andrei Alexandrescu wrote: >>>>> downs wrote: >>>>>> Andrei Alexandrescu wrote: >>>>>>> downs wrote: >>>>>>>> Andrei Alexandrescu wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> >>>>>>>>> D currently allows defining class allocators and deallocators. >>>>>>>>> They >>>>>>>>> have >>>>>>>>> a number of problems that make them unsuitable for D 2.0. The most >>>>>>>>> obvious issue is that D 2.0 will _not_ conflate destruction with >>>>>>>>> deallocation anymore: invoking delete against an object will call >>>>>>>>> ~this() against it but will not recycle its memory. In contrast, >>>>>>>>> class >>>>>>>>> deallocators are designed around the idea that invoking delete >>>>>>>>> calls the >>>>>>>>> destructor and also deallocates memory. >>>>>>>>> >>>>>>>>> So I'm thinking of removing at least class deallocators from the >>>>>>>>> language. Class allocators may be marginally and occasionally >>>>>>>>> useful if >>>>>>>>> the user takes the matter of deallocation in her own hands. >>>>>>>>> >>>>>>>>> A much better way to handle custom allocation of classes would be >>>>>>>>> in the >>>>>>>>> standard library. >>>>>>>>> >>>>>>>>> What do you think? >>>>>>>>> >>>>>>>>> >>>>>>>>> Andrei >>>>>>>> Do you trust the D GC to be good enough to always free everything >>>>>>>> you've allocated, without error? >>>>>>>> >>>>>>>> If your answer was 'ye- maaybe ... no actually', please rethink >>>>>>>> this. >>>>>>> People will always be able to call functions in the garbage >>>>>>> collector >>>>>>> manually. The discussion on class allocators and deallocators has >>>>>>> nothing to do with that. >>>>>>> >>>>>>> Andrei >>>>>> So you can still deallocate a class by hand, only it's not called >>>>>> delete anymore? >>>>> That is correct. >>>>> >>>>> Andrei >>>> Isn't that a pretty big violation of Least Surprise? >>>> >>>> http://en.wikipedia.org/wiki/Principle_of_least_astonishment : >>>> "In user interface design, programming language design, and >>>> ergonomics, the principle (or rule or law) of least astonishment (or >>>> surprise) states that, when two elements of an interface conflict, or >>>> are ambiguous, the behaviour should be that which will *least >>>> surprise* the human user or programmer at the time the conflict >>>> arises." >>> I think the basic rule being introduced is: >>> that every object can be managed by the gc, or manually managed. But not >>> both. That seems reasonable to me. But if delete no longer deletes, it >>> needs a name change. >> >> >> Oh, that makes more sense. >> >> Do manually managed objects still count under Mark&Sweep? > > You have to register the memory range they cover to the GC if they > contain pointers to GC memory. Otherwise the GC don't know they exist at > all.
Well I certainly wouldn't expect that! :p This sounds like something that might trip people up. I believe at least scanning objects by GC should always be the default for any object, if only because the association "D heap => GC managed" is I think a fairly core part of the language.