www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 11949] New: Warning and later deprecation message for usage of delete

reply d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11949

           Summary: Warning and later deprecation message for usage of
                    delete
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: diagnostic
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: bearophile_hugs eml.cc



I suggest to give a warning for the usage of delete, and later give a
deprecation message:


void main() {
    auto p = new int;
    delete p;
}

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 19 2014
next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11949


rswhite4 googlemail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rswhite4 googlemail.com



I'm still against that. delete free's and finalize the memory which is quite
good. destroy (the replacement for delete) is bug prone and don't free the
underlying memory. And since the GC isn't that good, delete is still nice to
have.
AFAIK the main reason why delete was choosen to be deprecated, was, that it
makes assumptions over the allocation method, in this case the GC. But IMO that
is no valid reason because it is sometimes good to controle the GC since it is
and will not be that good in the near future.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 19 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11949


Stanislav Blinov <stanislav.blinov gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |stanislav.blinov gmail.com



05:37:47 PST ---
I'm with bearophile on this. If something goes away, let it go away. I may not
be an active member of D community, but I am interested in writing software in
D. This "ought to be deprecated but isn't, and what's the replacement?.." thing
shouldn't last, it only brings confusion.

Phobos has to be improved, libraries have to be written, software has to be
written. How to do this reliably when there's no clarity on which language
features should and shouldn't be used? 

This situation with delete. delete? destroy? clear? eradicate? Even now in
Phobos one can find both delete and destroy being used. Adding any new module
makes the "future" deprecation that much harder (and new modules are being
reviewed even now).

By not forcing the issue now, we're effectively introducing problems that would
come up "in the near future". Or we'd end up with Phobos and other libraries
cluttered with version blocks a-la C++'s glorified ifdef bundles that manage
"deficincies" of various implementations.

I was watching last year's DConf recently. And Andrei Alexandrescu presented a
good case of required quality. Quality does not couple well with such
ambiguities.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 19 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11949


hsteoh quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsteoh quickfur.ath.cx



I vote for this deprecation. If you need to manually free stuff, use
malloc/free instead, don't use the GC. If you use the GC, don't use delete
(there's still GC.free if you absolutely have to, but the language itself
shouldn't support such an unsafe operation as a built-in keyword).

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 19 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11949


Maxim Fomin <maxim maxim-fomin.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |maxim maxim-fomin.ru



---

 I'm with bearophile on this. If something goes away, let it go away. I may not
 be an active member of D community, but I am interested in writing software in
 D. This "ought to be deprecated but isn't, and what's the replacement?.." thing
Rest nonsense is skipped. Do you now that removing delete actually hurts programming? I am fine that you are interested in writing D code, but asking to remove necessary feature which may be used by other people is bad idea. Delete is actually needed because without it memory management really gets hurt. Without delete and especially overriding new and delete operator methods there is no way to allocate memory for classes in user-friendly way. One need to use old malloc/free or whatever function to allocate mem in specified place. Why should this be done if there is already syntax and semantic for this? If delete and respective class methods are removed, this will increase problem of optional GC. In my view removing delete is like removing scope(XXX) because same effects can be achieved by try-catch-finally blocks. In addition, multiple replacements - destroy, clear and whatever it is, not only do not address the problems, but are crippled. Removing delete belongs to the same basket as removing typedef: a good feature is removed without any valid reasons some years ago and there are still complains that replacement (Typedef struct) does not work. Besides being useful, there is _zero_ real arguments against delete except Andrei's (who is essentially saying that delete contradicts his subjective views about nice and good code - I tried to figure some grounds and failed, he essentially repeats like in case of typedef that the feature is 'bad'). -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 20 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11949




02:44:27 PST ---


 I'm with bearophile on this. If something goes away, let it go away. I may not
 be an active member of D community, but I am interested in writing software in
 D. This "ought to be deprecated but isn't, and what's the replacement?.." thing
Rest nonsense is skipped.
Well, now that's a nice way to support discussion. You would forgive me if my tone in this message may seem slightly not level.
 Do you now that removing delete actually hurts
 programming? I am fine that you are interested in writing D code, but asking to
 remove necessary feature which may be used by other people is bad idea.
What hurts programming are features that are hanging in the air. You seem to have missed the general message of my post in that regard. Oh wait, no, you just dismissed it as "nonsense".
 Delete is actually needed because without it memory management really gets
 hurt. Without delete and especially overriding new and delete operator methods
 there is no way to allocate memory for classes in user-friendly way. One need
 to use old malloc/free or whatever function to allocate mem in specified place.
Are you writing custom memory managers all day long? Or once a month, once a year? Couldn't you then present a really good and strong case as to why delete should stay? Complete with examples, rationales, resolved issues? Without generalizations a-la "people use it all the time"? In any discussion, a good argument should be reasonable and has to have grounds, otherwise it is easily dismissed, don't you think? Strictly from a user's point of view, there is no need for delete keyword in a garbage-collected language. None. By definition. More of it, even modern C++, of all things, strives to put some distance between user code and new/delete. Because a streamlined user-friendly language should not burden users with technical aspects of memory allocation. Because users are likely to get it wrong. That may seem like a generalization I myself asked to stay away from, but in this case, it is not. It's a proven fact. Otherwise, we wouldn't need garbage collection, smart pointers, exception safety, RAII and all the other fancy stuff and would just go on writing malloc and free all the time and be happy. I consider myself lucky in regards that I actually had to write custom memory manager once. Both because I had an opportunity to do it, and because it was a single occasion (i.o.w. I hope to never have to do that again, especially in this concurrent world).
 Why should this be done if there is already syntax and semantic for this? If
 delete and respective class methods are removed, this will increase problem of
 optional GC.
If they are bluntly removed - yes. But that's what this is all about: resolving outstanding issues and getting rid of ambiguity. Of course, this *does* include providing good alternatives for cases of manual memory management (i.e. absent or alternative GC). Believe me, I perfectly understand the need for *some* form of control, but it has no business being in user land.
 In my view removing delete is like removing scope(XXX) because same effects can
 be achieved by try-catch-finally blocks. 
I am sorry, were built-in scope guards declared to be removed from the language? Because if they weren't, I don't see the point in that comment. Or, if you would allow me to make an observation: if your usage of "delete" keyword in your D code is on par with your usage of scope guards, you're positively doing something wrong, even if it's just sticking to habits from other language(s).
 In addition, multiple replacements -
 destroy, clear and whatever it is, not only do not address the problems, but
 are crippled. 
Of course they are. Because the subject is still in the air, without any definitive resolution. But that's nonsense...
 Removing delete belongs to the same basket as removing typedef: a
 good feature is removed without any valid reasons some years ago and there are
 still complains that replacement (Typedef struct) does not work. 
Just because you are used to something doesn't make it right or wrong. What matters are certain experiences and practicality. typedef keyword *was* a dubious feature for a language that allows for user types with arbitrary semantics. Simply because to be usable it'd either have to degrade to alias, or grow into... uh, I don't know, struct? delete keyword is in the same pool: to be practical it either has to be mandatory, or go away into some land where it actually matters (i.e. custom allocators).
 Besides being useful, there is _zero_ real arguments against delete except
 Andrei's (who is essentially saying that delete contradicts his subjective
 views about nice and good code - I tried to figure some grounds and failed, he
 essentially repeats like in case of typedef that the feature is 'bad').
I'll repeat my argument from above just in case you "nonsensed" it: most of the users get memory management wrong. Yet it is them who write most of the software. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 20 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11949




---

 What hurts programming are features that are hanging in the air. You seem to
 have missed the general message of my post in that regard. Oh wait, no, you
 just dismissed it as "nonsense".
The rest of the message was devoted to how you are confused with delete/destroy/clear and that absense of clearity in this issue somehow hurts writing code. This is nonsense. There are plenty of non-clarities, lets start from sparse spec in dlang.org. What you are saying is like lets burn type tuples in dmd and phobos because someone is confused between them.
 Delete is actually needed because without it memory management really gets
 hurt. Without delete and especially overriding new and delete operator methods
 there is no way to allocate memory for classes in user-friendly way. One need
 to use old malloc/free or whatever function to allocate mem in specified place.
Are you writing custom memory managers all day long? Or once a month, once a year?
Does not matter. It is used sometimes. Because the feature is used rarely is not a valid reason to drop it. The language design is consistent not when there is nothing to add, but nothing to drop.
 Couldn't you then present a really good and strong case as to why delete
 should stay? Complete with examples, rationales, resolved issues? Without
 generalizations a-la "people use it all the time"? In any discussion, a good
 argument should be reasonable and has to have grounds, otherwise it is easily
 dismissed, don't you think?
byte[16] buf; class A { void* new () { return buf.ptr; } } //as singleton in D. class B { void* new(void *ptr) { return ptr; } } void main() { byte[16] b; B b1 = new B(b.ptr); } // as class alocated on stack Add to this nice manual memory management and inability of destroy() to release memory and you have good reasons not to drop delete. By the way, as I keep saying, there are exactly zero good reasons to drop delete.
 Strictly from a user's point of view, there is no need for delete keyword in a
 garbage-collected language. None. By definition.
Nope. D is advertized as free from garbage collection, so it should support memory management.
 More of it, even modern C++,
which is irrelevant.
 Because users are likely to get it wrong.
Being likely to get it wrong is not a reason to remove feature.
 
 Why should this be done if there is already syntax and semantic for this? If
 delete and respective class methods are removed, this will increase problem of
 optional GC.
If they are bluntly removed - yes. But that's what this is all about: resolving outstanding issues and getting rid of ambiguity. Of course, this *does* include providing good alternatives for cases of manual memory management (i.e. absent or alternative GC). Believe me, I perfectly understand the need for *some* form of control, but it has no business being in user land.
 In my view removing delete is like removing scope(XXX) because same effects can
 be achieved by try-catch-finally blocks. 
I am sorry, were built-in scope guards declared to be removed from the language? Because if they weren't, I don't see the point in that comment. Or, if you would allow me to make an observation: if your usage of "delete" keyword in your D code is on par with your usage of scope guards, you're positively doing something wrong, even if it's just sticking to habits from other language(s).
 In addition, multiple replacements -
 destroy, clear and whatever it is, not only do not address the problems, but
 are crippled. 
Of course they are. Because the subject is still in the air, without any definitive resolution. But that's nonsense...
The fact that they are crippled is a sign that delete is good actually because despite years of depreciation nobody managed to come up with sound alternative.
 Removing delete belongs to the same basket as removing typedef: a
 good feature is removed without any valid reasons some years ago and there are
 still complains that replacement (Typedef struct) does not work. 
Just because you are used to something doesn't make it right or wrong. What matters are certain experiences and practicality.
The paradox - people who ofter refer to experience and practice often propose changes which show problems when applied into experience and practice.
 typedef keyword *was* a
 dubious feature for a language that allows for user types with arbitrary
 semantics. Simply because to be usable it'd either have to degrade to alias, or
 grow into... uh, I don't know, struct? delete keyword is in the same pool: to
 be practical it either has to be mandatory, or go away into some land where it
 actually matters (i.e. custom allocators).
 
 Besides being useful, there is _zero_ real arguments against delete except
 Andrei's (who is essentially saying that delete contradicts his subjective
 views about nice and good code - I tried to figure some grounds and failed, he
 essentially repeats like in case of typedef that the feature is 'bad').
I'll repeat my argument from above just in case you "nonsensed" it: most of the users get memory management wrong. Yet it is them who write most of the software.
If you are stupid enough to not understand memory management and system level, then don't write code in for it. Some people do, and it is important for them. D is system language, this is written in main page, TDPL by Andrei and often highlighted by Walter (like saying that system language should have asm) The real problem is that some uninformed users sometimes offer to remove the feature (or change the language in general case) because it is 'bad', 'not type safe', is not 'fancy'. These uninformed users, typically lack experience or come into language recently, do not know difference between language and library, but do like to post wordy messages with empty meaning to look smart. On surface, their proposals looks reasonable, but because nobody investigates the issue deeply or forgets about some corner case, their naive proposals result into compounding problems. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 20 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11949


yebblies <yebblies gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yebblies gmail.com




 
 Does not matter. It is used sometimes. Because the feature is used rarely is
 not a valid reason to drop it. The language design is consistent not when there
 is nothing to add, but nothing to drop.
 
That is the second most important reason to remove a feature.
 
 Being likely to get it wrong is not a reason to remove feature.
 
And this is the most important reason. If you're going to be arrogant and rude, you could at least be correct. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 20 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11949




05:11:52 PST ---


 The rest of the message was devoted to how you are confused with
 delete/destroy/clear and that absense of clearity in this issue somehow hurts
 writing code. This is nonsense. There are plenty of non-clarities, lets start
 from sparse spec in dlang.org. What you are saying is like lets burn type
 tuples in dmd and phobos because someone is confused between them. 
Please don't put words into my mouth. If it is so necessary to clarify, I will do so: I was referring to the situation with "virtually deprecated" features in D. The ones that are going away, but haven't yet. Because there are no alternatives, no library replacements, no clear solutions, etc. The situation with "delete" is one of them. How do you propose to write libraries and programs in a systems language when it's not clearly defined?
 Are you writing custom memory managers all day long? Or once a month, once a
 year?
Does not matter. It is used sometimes. Because the feature is used rarely is not a valid reason to drop it. The language design is consistent not when there is nothing to add, but nothing to drop.
Which means that everything that *does* have to be to be dropped... has to be dropped. // Code cut out
 
 void main()
 {
   byte[16] b;
   B b1 = new B(b.ptr);
 }
 
 // as class alocated on stack
 
 Add to this nice manual memory management and inability of destroy() to release
 memory and you have good reasons not to drop delete. By the way, as I keep
 saying, there are exactly zero good reasons to drop delete.
I am sorry, but that example is (a) contrived, (b) unsafe, and (c) if I am not mistaken, already has a library implementation. And (d) it looks like (using Andrei's terminology) "C+", only in D; in other words, has little to do with the language being discussed.
 Strictly from a user's point of view, there is no need for delete keyword in a
 garbage-collected language. None. By definition.
Nope. D is advertized as free from garbage collection, so it should support memory management.
It seems to me we're talking about two different things. Or in different languages. D is "advertised" as a "language with automatic memory management" firsthand. Yes, the possibility of explicit (manual) memory management does exist. And, sadly, it is still described in terms of "new/delete" keywords, despite the fact that "delete" was declared obsolete long ago. Removing "delete" keyword in its existing form and semantics has nothing to do with forbidding you from performing manual memory management. But the thing is with manual memory management is that it is... uh... manual. And as such, shall be easily distinguishable. You may say "well yes, and delete precisely states the intent". It doesn't. Were it that D *did not* have garbage collection in the first place, such argument would be valid. There are three distinct memory management issues worth separating out: 1) Garbage collector present. In 99% of the cases, it's smarter than you, and trying to coerce it into specific behavior should be really, *really* explicit (read very long and nasty function names). Except from library (as in, Phobos, or a very specific, corner-case library), (in other words: in user code) you would never need to explicitly "delete" your objects. Runtime will detect dangling references and the GC will recycle memory as it sees fit. Thus, "delete" keyword is redundant. 2) No garbage collector. In this case, you *do* need some low-level mechanism to allocate memory for all your objects and then free it when it's no longer needed (C, C++). At first it would seem that in this case new/delete is quite enough. And it would be, if case (1) did not exist. In order for user (and library) code to be compatible with *both* (1) and (2), the operations should be transparent. For example, as one of the solutions for this case, the runtime should still be capable to detect a dangling reference (remember, unlike C and C++ D *does* have distinct reference types) and immediately call your "oh so very custom and low-level" deallocator. That's it. There may be other solutions, I'm just stating the plain and obvious one. X) I specifically don't mark this with "3", because this case can be built on top of both (1) and (2). That is when you (after very long and excruciating deliberation) have come to conclusion that you *do* need to manually manage allocation for a particular type (or types) in your application (library). And this case has *absolutely nothing* to do with either "new" or "delete". Explicit is explicit, write your own functions and move on.
 More of it, even modern C++,
which is irrelevant.
Hmm... where did that picture with orly owl go?.. Indeed, one of the biggest systems languages in the world is irrelevant. Ouch.
 Being likely to get it wrong is not a reason to remove feature.
Again, it seems we're not seeing the "feature" in the same light.
 destroy, clear and whatever it is, not only do not address the problems, but
 are crippled. 
Of course they are. Because the subject is still in the air, without any definitive resolution. But that's nonsense...
The fact that they are crippled is a sign that delete is good actually because despite years of depreciation nobody managed to come up with sound alternative.
This logic just does not compute. The fact that there is no "sound alternative" reads simply as "nobody sat down and implemented one yet". Because there are seemingly/genuinely more important things to do. By requesting to *actually* deprecate what is already deprecated, we're forcing the issue. That's it.
 Just because you are used to something doesn't make it right or wrong. What
 matters are certain experiences and practicality.
The paradox - people who ofter refer to experience and practice often propose changes which show problems when applied into experience and practice.
Yes, indeed. That's what people said about STL when it first came about. Said *and* went to great lengths to avoid it. Sigh...
 I'll repeat my argument from above just in case you "nonsensed" it: most of the
 users get memory management wrong. Yet it is them who write most of the
 software.
If you are stupid enough
Hmm, this is twice in a row you have insulted me, seemingly just because we have a disagreement. If that is your way of having a discussion or trying to make your case, I am very sorry for you. My only hope is that whatever troubles in your life that make you so bitter do resolve, first of all so you could be a happier person, and secondly so we could have more productive discussions in the future.
 to not understand memory management and system level,
I undertand it well enough to not have to imlement any of it ever again.
 then don't write code in for it. 
That is simply not true. You're confusing memory model and memory management. To write correct code for modern architectures, one has to understand memory model. Even not that, if one's rusted or conservative and only ever have one thread. But in either case one can happily stay totally oblivious to how memory allocators work, and still write quality code, as long as one *does not violate* the operation of those allocators. I hope you see which way I'm going with this.
 Some people do, and it is important for them.
 D is system language, this is written in main page, TDPL by Andrei and often
 highlighted by Walter (like saying that system language should have asm)
This, again, does not mean that writing good code in such language requires you to be a Ph.D in every possible computing discipline. // The rest cut out as hinging on pure speculation -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 20 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11949


Jonathan M Davis <jmdavisProg gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg gmx.com



PST ---
There really is no question that delete is going to be removed. It's been
discussed a number of times before, and the decision was most definitely that
it's going away. The same functionality can be achieved through library
functions (e.g. GC.malloc or C's malloc plus emplace and GC.free or C's free),
so we don't need it in the language itself in order to get the functionality,
and having it in the language encourages its use, when its use should be
discouraged (the functionality should still be there for those who really
needed, but it shouldn't be in your average D program). Andrei in particular
feels very strongly that delete has no business in the core language. If
anything, it should have been removed long since. AFAIK, the only reason that
it's still around is that none of the compiler devs have gotten around to
removing it.

The best that anyone who really wants delete to stay is going to get is a delay
in its removal. And such a delay would just increase the amount of code that
breaks when it happens. So, it's in our best interest to deprecate it and put
it on the path to removal ASAP rather than arguing over what's already been
decided.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 20 2014
prev sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11949


monarchdodra gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |monarchdodra gmail.com




 There really is no question that delete is going to be removed. It's been
 discussed a number of times before, and the decision was most definitely that
 it's going away. The same functionality can be achieved through library
 functions (e.g. GC.malloc or C's malloc plus emplace and GC.free or C's free),
 so we don't need it in the language itself in order to get the functionality,
 and having it in the language encourages its use, when its use should be
 discouraged (the functionality should still be there for those who really
 needed, but it shouldn't be in your average D program). Andrei in particular
 feels very strongly that delete has no business in the core language. If
 anything, it should have been removed long since. AFAIK, the only reason that
 it's still around is that none of the compiler devs have gotten around to
 removing it.
 
 The best that anyone who really wants delete to stay is going to get is a delay
 in its removal. And such a delay would just increase the amount of code that
 breaks when it happens. So, it's in our best interest to deprecate it and put
 it on the path to removal ASAP rather than arguing over what's already been
 decided.
Seriously, why isn't it the damn thing deprecated already? I got into D about 2 years ago, and already, there were people saying to not use it, because it's going away. If we decide something goes, it gets marked as deprecated. If it was an important feature, it stays deprecated for a long time. Saying something will be removed, but keeping it around as is makes no sense to me. It stays or it goes. Preferably goes. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 20 2014