https://d.puremagic.com/issues/show_bug.cgi?id=11949
--- Comment #5 from Stanislav Blinov <[email protected]> 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: -------
