[Issue 11949] Warning and later deprecation message for usage of delete

[d-bugmail at puremagic.com]

https://d.puremagic.com/issues/show_bug.cgi?id=11949



--- Comment #8 from Stanislav Blinov <stanislav.blinov at gmail.com> 2014-01-20 05:11:52 PST ---
(In reply to comment #6)
> (In reply to comment #5)
> 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: -------