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

d-bugmail at puremagic.com d-bugmail at puremagic.com
Mon Jan 20 02:44:35 PST 2014


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



--- Comment #5 from Stanislav Blinov <stanislav.blinov at gmail.com> 2014-01-20 02:44:27 PST ---
(In reply to comment #4)
> (In reply to comment #2)
> > 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: -------


More information about the Digitalmars-d-bugs mailing list