More radical ideas about gc and reference counting

H. S. Teoh via Digitalmars-d digitalmars-d at puremagic.com
Thu May 1 07:04:07 PDT 2014


On Thu, May 01, 2014 at 10:06:17AM +0000, monarch_dodra via Digitalmars-d wrote:
> On Wednesday, 30 April 2014 at 23:19:18 UTC, H. S. Teoh via Digitalmars-d
> wrote:
> >On Wed, Apr 30, 2014 at 03:55:38PM -0700, Andrei Alexandrescu via
> >Digitalmars-d wrote:
> >>On 4/30/14, 3:47 PM, H. S. Teoh via Digitalmars-d wrote:
> >[...]
> >>>I don't like the sound of that. I haven't found myself in a >place
> >>>where I needed to do something like this, but if I had to, >I'd be
> >>>very unhappy if struct dtors only work when they're not class
> >>>members. Can we make them always work, and if necessary >prohibit
> >>>using them as class members?
> >>
> >>Then we're back to effectively class destructors. I think we've
> >>gathered quite a bit of evidence there are pernicious issues
> >>associated with them. -- Andrei
> >[...]
> >
> >How so? If we prohibit structs with dtors from being class members,
> >then it could work.
> 
> Why would we prohibit structs with destructors from being class
> members?  That don't make sense to me.

The proposal was to get rid of class dtors at some point. Which will
introduce the problem of what to do when a class member is a struct with
a dtor, since that dtor will never run.


> "A class is allowed to have a destructor" <=> "A class can have
> members with destructors".
> 
> So we either kill off class destructor entirelly (which would mean no
> members with destructors) (But that seems like a bad idea), or we keep
> both.
> 
> Or did I miss something in the argument?

Yes that's the gist of it. But Andrei seems to be convinced that class
dtors are a bad idea, so to me, that also implies that class members
with dtors are an equally bad (or worse) idea, so therefore they must be
gotten rid of too.


T

-- 
All problems are easy in retrospect.


More information about the Digitalmars-d mailing list