[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 #6 from Maxim Fomin <maxim at maxim-fomin.ru> 2014-01-20 03:37:19 PST ---
(In reply to comment #5)
>
> 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: -------