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?
