www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: poll about delete

reply F. Almeida <francisco.m.almeida gmail.com> writes:
About a week ago (or more), I posted a poll to gather the community
opinion on how memory management in D should evolve. Link is
http://www.micropoll.com/akira/mpview/979834-265542

Last I saw, more than half of the D users who voted in it would prefer
that the delete keyword would remain in the language, instead of being
removed. Some of those don't even see a need for a clear() function,
but I disagree with them, I think it will be useful.

On the other hand, just because new safe memory management functions
are to be added to the standard library, that is no justification to
turn D into less of a systems programming language. Which is what will
happen if we give preference to the GC instead of making both styles
(managed or not managed, safe or unsafe) equally easy to adopt to any
programmer. This is the most attractive aspect of D and shouldn't be
discarded.
Jul 27 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
F. Almeida wrote:
 About a week ago (or more), I posted a poll to gather the community
 opinion on how memory management in D should evolve. Link is
 http://www.micropoll.com/akira/mpview/979834-265542
 
 Last I saw, more than half of the D users who voted in it would prefer
 that the delete keyword would remain in the language, instead of being
 removed. Some of those don't even see a need for a clear() function,
 but I disagree with them, I think it will be useful.
 
 On the other hand, just because new safe memory management functions
 are to be added to the standard library, that is no justification to
 turn D into less of a systems programming language. Which is what will
 happen if we give preference to the GC instead of making both styles
 (managed or not managed, safe or unsafe) equally easy to adopt to any
 programmer. This is the most attractive aspect of D and shouldn't be
 discarded.

It's difficult to take a meaningful poll without clearly informing the voters about the context of the vote and the arguments brought about. I apologize for my hard stance on the matter but I really think there is no case in favor of keeping delete. - The operation didn't deserve a keyword in the C++ days, and carrying that keyword along is completely gratuitous. - Most code and most coders would be dramatically helped by distinguishing destruction from deletion, as opposed to the wrong conflation implicitly fostered by C++ for years. - D is a systems language, but it's also a language in which doing the right thing is easy and favored. Allocating no less than a keyword for a fundamentally unsafe operation is just too much. - The GC can't be expected to implement manual disposal anyway. Again, allocating a _keyword_ for an operation that may actually end up not doing much at all is overkill. Honestly the top thing I'm worried right now is Walter's aversion to breaking changes, which has turned an elbow since TDPL. I think he is convinced delete must be deleted as much as I am, but right now it's possible he'd rather have it limp along a slow deprecation process instead of outright removing it. Many of the same arguments and considerations apply to "scope" as a storage class. In brief: it's best to not use the likes of "scope" (storage class) and "delete" in new code, remove it from old code, and propose library features that help with such unsafe use cases. I think it is a waste of time arguing in favor of the status quo unless new strong arguments come to the table. Andrei
Jul 27 2010
parent reply Kagamin <spam here.lot> writes:
Andrei Alexandrescu Wrote:

 - Most code and most coders would be dramatically helped by 
 distinguishing destruction from deletion, as opposed to the wrong 
 conflation implicitly fostered by C++ for years.

So you just want to have control what you destruct and what you delete? For what reason?
 - D is a systems language, but it's also a language in which doing the 
 right thing is easy and favored. Allocating no less than a keyword for a 
 fundamentally unsafe operation is just too much.

The language can't guarantee it's unsafety. You can tell whether an object's destructor was called, but you can't tell whether a memory chunk was freed.
 - The GC can't be expected to implement manual disposal anyway.

This expectation is not easy to verify. If you want GC to not free, why you bother if it doesn't free?
 allocating a _keyword_ for an operation that may actually end up not 
 doing much at all is overkill.

This seems to be the only argument that's hard to object to, and it seems to be the main one. So is that it?
 Honestly the top thing I'm worried right now is Walter's aversion to 
 breaking changes, which has turned an elbow since TDPL.

I doubt that keyword saving is a good argument for a breaking change. btw can a function destruct object and nullify pointer for both rvalue and lvalue?
Jul 27 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Kagamin wrote:
 Andrei Alexandrescu Wrote:
 
 - Most code and most coders would be dramatically helped by 
 distinguishing destruction from deletion, as opposed to the wrong 
 conflation implicitly fostered by C++ for years.

So you just want to have control what you destruct and what you delete? For what reason?

This has been often discussed in numerous fora. Essentially destruction can be made safe but memory reclamation cannot (with qualifications).
 - D is a systems language, but it's also a language in which doing
 the right thing is easy and favored. Allocating no less than a
 keyword for a fundamentally unsafe operation is just too much.

The language can't guarantee it's unsafety. You can tell whether an object's destructor was called, but you can't tell whether a memory chunk was freed.

I'm not sure where this leaves the conversation.
 - The GC can't be expected to implement manual disposal anyway.

This expectation is not easy to verify. If you want GC to not free, why you bother if it doesn't free?

I bother about primitives that essentially can't guarantee anything.
 allocating a _keyword_ for an operation that may actually end up
 not doing much at all is overkill.

This seems to be the only argument that's hard to object to, and it seems to be the main one. So is that it?

Plus all others, none of which was successfully retorted.
 Honestly the top thing I'm worried right now is Walter's aversion
 to breaking changes, which has turned an elbow since TDPL.

I doubt that keyword saving is a good argument for a breaking change. btw can a function destruct object and nullify pointer for both rvalue and lvalue?

It doesn't matter. delete nullifying its argument was a false sense of safety anyway - like the helmet of a kamikaze. Andrei
Jul 27 2010
parent reply Justin Spahr-Summers <Justin.SpahrSummers gmail.com> writes:
On Tue, 27 Jul 2010 11:36:19 -0700, Jonathan M Davis 
<jmdavisprog gmail.com> wrote:
 At minimum, we should have a list 
 of features which are still in dmd but which are (or should be) deprecated so 
 that we know what not to use (along with actually deprecating everything
that's 
 supposed to be deprecated but not yet outright removed).

Agreed! I only know which language features to avoid because I lurk in the newsgroups. Programmers new to D have no idea what's scheduled for deprecation. This kind of list has been suggested multiple times, but I strongly believe that someone with a hand in the language itself (e.g., Andrei) should just take 30 minutes one day and compile an authoritative reference.
Jul 27 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Justin Spahr-Summers wrote:
 On Tue, 27 Jul 2010 11:36:19 -0700, Jonathan M Davis 
 <jmdavisprog gmail.com> wrote:
 At minimum, we should have a list 
 of features which are still in dmd but which are (or should be) deprecated so 
 that we know what not to use (along with actually deprecating everything
that's 
 supposed to be deprecated but not yet outright removed).

Agreed! I only know which language features to avoid because I lurk in the newsgroups. Programmers new to D have no idea what's scheduled for deprecation. This kind of list has been suggested multiple times, but I strongly believe that someone with a hand in the language itself (e.g., Andrei) should just take 30 minutes one day and compile an authoritative reference.

Walter plans to change the documentation to reflect the demise of delete and scope storage class. Andrei
Jul 27 2010
parent reply Max Samukha <spambox d-coding.com> writes:
On 07/27/2010 10:53 PM, Andrei Alexandrescu wrote:
 and scope storage class.

If scope storage class is going, we need a library equivalent. Current 'scoped' is not good due to 4500.
Jul 27 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Max Samukha wrote:
 On 07/27/2010 10:53 PM, Andrei Alexandrescu wrote:
 and scope storage class.

If scope storage class is going, we need a library equivalent. Current 'scoped' is not good due to 4500.

Agreed. I know how to fix it. Andrei
Jul 27 2010
next sibling parent Max Samukha <spambox d-coding.com> writes:
On 07/27/2010 11:17 PM, Andrei Alexandrescu wrote:
 Max Samukha wrote:
 On 07/27/2010 10:53 PM, Andrei Alexandrescu wrote:
 and scope storage class.

If scope storage class is going, we need a library equivalent. Current 'scoped' is not good due to 4500.

Agreed. I know how to fix it.

Interesting. I can only think of allocating the class on a separate stack.
Jul 27 2010
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 Agreed. I know how to fix it.

Can you tell the idea? -------- Another thing: currently somewhere in DMD there is some code that tests against returning a scoped object: class Foo {} Foo bar() { scope Foo f = new Foo; return f; } void main() {} That code generates the error: test.d(4): Error: escaping reference to scope local f While currently this doesn't generate a compile-time error: class Foo {} Foo bar() { Foo f = scoped!Foo(); return f; } void main() {} This bug report shows that 'scoped' can cause other bugs: http://d.puremagic.com/issues/show_bug.cgi?id=4214 But catching some of the most common bugs is positive, so can the code present in dmd used to catch and avoid the return of a scoped object be used to avoid the return of the library-defined scoped!() object? Bye, bearophile
Jul 27 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:
 Andrei Alexandrescu:
 Agreed. I know how to fix it.

Can you tell the idea?

Either define an explicit Scope type, or use the alloca() as a default parameter trick.
 Another thing: currently somewhere in DMD there is some code that tests
against returning a scoped object:
 
 class Foo {}
 Foo bar() {
     scope Foo f = new Foo;
     return f;
 }
 void main() {}
 
 That code generates the error:
 test.d(4): Error: escaping reference to scope local f
 
 While currently this doesn't generate a compile-time error:
 
 class Foo {}
 Foo bar() {
     Foo f = scoped!Foo();
     return f;
 }
 void main() {}
 
 This bug report shows that 'scoped' can cause other bugs:
 http://d.puremagic.com/issues/show_bug.cgi?id=4214
 
 But catching some of the most common bugs is positive, so can the code present
in dmd used to catch and avoid the return of a scoped object be used to avoid
the return of the library-defined scoped!() object?
 
 Bye,
 bearophile

I think with memory safety it's a 0/1 proposition. The current "scope" keyword being "somewhat pregnant" is worse than not at all because it lulls its user into a false sense of security. Andrei
Jul 27 2010
prev sibling parent reply Graham St Jack <Graham.StJack internode.on.net> writes:
On 28/07/10 05:47, Andrei Alexandrescu wrote:
 Max Samukha wrote:
 On 07/27/2010 10:53 PM, Andrei Alexandrescu wrote:
 and scope storage class.

If scope storage class is going, we need a library equivalent. Current 'scoped' is not good due to 4500.

Agreed. I know how to fix it. Andrei

I missed the previous discussions about removing the scoped storage class. Would you mind re-stating the argument here, or post a link to it? FWIW I'm happy for delete to be removed. -- Graham St Jack
Jul 27 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Graham St Jack wrote:
 On 28/07/10 05:47, Andrei Alexandrescu wrote:
 Max Samukha wrote:
 On 07/27/2010 10:53 PM, Andrei Alexandrescu wrote:
 and scope storage class.

If scope storage class is going, we need a library equivalent. Current 'scoped' is not good due to 4500.

Agreed. I know how to fix it. Andrei

I missed the previous discussions about removing the scoped storage class. Would you mind re-stating the argument here, or post a link to it? FWIW I'm happy for delete to be removed.

In brief scope is unsafe and impossible to make safe without extensive changes to the language. Andrei
Jul 27 2010
parent reply Graham St Jack <Graham.StJack internode.on.net> writes:
On 28/07/10 07:50, Andrei Alexandrescu wrote:
 Graham St Jack wrote:
 On 28/07/10 05:47, Andrei Alexandrescu wrote:
 Max Samukha wrote:
 On 07/27/2010 10:53 PM, Andrei Alexandrescu wrote:
 and scope storage class.

If scope storage class is going, we need a library equivalent. Current 'scoped' is not good due to 4500.

Agreed. I know how to fix it. Andrei

I missed the previous discussions about removing the scoped storage class. Would you mind re-stating the argument here, or post a link to it? FWIW I'm happy for delete to be removed.

In brief scope is unsafe and impossible to make safe without extensive changes to the language. Andrei

Thanks. I definitely agree that it should go if it can't be made to work properly. -- Graham St Jack
Jul 27 2010
parent Max Samukha <spambox d-coding.com> writes:
On 07/28/2010 01:36 AM, Graham St Jack wrote:
 On 28/07/10 07:50, Andrei Alexandrescu wrote:
 Graham St Jack wrote:
 On 28/07/10 05:47, Andrei Alexandrescu wrote:
 Max Samukha wrote:
 On 07/27/2010 10:53 PM, Andrei Alexandrescu wrote:
 and scope storage class.

If scope storage class is going, we need a library equivalent. Current 'scoped' is not good due to 4500.

Agreed. I know how to fix it. Andrei

I missed the previous discussions about removing the scoped storage class. Would you mind re-stating the argument here, or post a link to it? FWIW I'm happy for delete to be removed.

In brief scope is unsafe and impossible to make safe without extensive changes to the language. Andrei

Thanks. I definitely agree that it should go if it can't be made to work properly.

Please be careful. Safe or not, anything should go only if it have a reasonable replacement. We don't need a safe but useless language.
Jul 28 2010
prev sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Tuesday, July 27, 2010 11:18:43 Andrei Alexandrescu wrote:
 It doesn't matter. delete nullifying its argument was a false sense of
 safety anyway - like the helmet of a kamikaze.

LOL. Ouch. That's a good one. In any case, I would strongly argue that even if we were to keep delete, it should be kept as a function rather than a keyword on the basis that we don't want to promote attempts at manual memory management with garbage collected memory. And if we don't think that it's a good idea to do that at all (which I would tend to agree with), then delete should be removed entirely. At this point, I get the impression that there is a subset of D users who want delete for whatever reason (be it misguided or legitimate), and they've been making noise about it, while many other D users don't care. I'm not sure that there are all that many people who are clamoring for its removal. Still, it's arguably more consistent _not_ to have delete, and if both you and Walter feel that it shouldn't be around, then I say that we should remove it. You're the main guys deciding what form the language takes, and this is definitely one of those cases where you're not going to get a consensus, so just do what you think is best. I would advise, however, that if we're going to deprecate features, they should still be removed sooner rather than later. Otherwise, not only will people continue to use them, but new D users will end up using them, which will make it harder to get rid of them cleanly. If many people are picking up TDPL, then we're going to be getting a definite increase in the number of people trying out D, and we don't want them to be using features that we intend to deprecate. I would hope that it would be a priority to bring dmd totally in line with TDPL, and remove features from the language that aren't supposed to be there anymore. It creates a fair bit of confusion otherwise. At minimum, we should have a list of features which are still in dmd but which are (or should be) deprecated so that we know what not to use (along with actually deprecating everything that's supposed to be deprecated but not yet outright removed). - Jonathan M Davis
Jul 27 2010