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
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 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
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