D Language 2.0

[Craig Black]

Andrei Alexandrescu Wrote:

> Craig Black wrote:
> > 
> > "Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
> > news:hj8gd7$2soe$1 at digitalmars.com...
> >> Craig Black wrote:
> >>>
> >>> "Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in 
> >>> message news:hj7vnu$2008$1 at digitalmars.com...
> >>>> BCS wrote:
> >>>>> Hello Andrei,
> >>>>>
> >>>>>> The nice part about refcounting is that for the most part you don't
> >>>>>> need to cripple the language.
> >>>>>>
> >>>>>
> >>>>> I think people are trying to say that disallowing use of GC stuff 
> >>>>> wouldn't cripple the language.
> >>>>
> >>>> Well it's a fact that there would be fewer idioms and options 
> >>>> accessible. So I didn't mean it in a derogatory way as much as a 
> >>>> factual statement.
> >>>>
> >>>>> Also there is one thing that -nogc would have over what you are 
> >>>>> talking about; you could use it on some modules and not others. If 
> >>>>> I have some performance critical code where attempting to use the 
> >>>>> GC would break it's perf contract, I can put it in it's own module 
> >>>>> and compile just it with -nogc and then link it in with code that 
> >>>>> does use the GC.
> >>>>
> >>>> Meh. This has been discussed in the C++ standardization committee, 
> >>>> and it gets really tricky real fast when you e.g. use together 
> >>>> several libraries, each with its own view of memory management. My 
> >>>> impression: don't.
> >>>
> >>> There are certainly challenges, even perhaps some that I haven't 
> >>> thought of, with mixing manual memory management and GC code.  But 
> >>> perhaps there is a bigger problem with the approach you describe.  
> >>> Correct me if I'm wrong, but it seems that what you propose is a 
> >>> -nogc option that would fragment all D code into two incompatible 
> >>> groups.  If my -nogc code could not be used with anyone else's D 
> >>> code, then what I have is not a dialect of D at all, but a different 
> >>> incompatible language.
> >>>
> >>> I know this issue is a challenging problem from a language design 
> >>> standpoint, and I see why you would have some disdain for it.  
> >>> However, this is not an impossible problem to solve.  For example, I 
> >>> believe Managed C++ does this, albeit with some weird syntax, but 
> >>> this proves that it can be done.  Anyway, just my 2 cents.
> >>
> >> It's reasonable to say that you decide at application design level 
> >> what memory management approach you want to choose. That doesn't 
> >> fragment the community. The decision is similar to many others made at 
> >> the same level: libraries used, build flags, target platform(s), 
> >> pointer size (32 vs. 64, not an option yet for dmd), etc.
> >>
> >> Andrei
> > 
> > Are we talking about the same thing here?  The things you mention here 
> > do not create two incompatible styles of programming.  I would like to 
> > point out how great it is that Phobos and Tango can be compiled together 
> > in the same application.  Now they are interoperable.  If -nogc code 
> > can't be used together with GC code, then we create a similar schism as 
> > having two incompatible "standard" libraries.
> 
> Well if we get into details we'll figure that things must be quite 
> different for different memory management models. For example Object in 
> ref-counted mode is not a class anymore, it's a struct. So now there's 
> going to be two parts in an app: those in which Object is a class, and 
> those in which Object is a struct. Reconciling those would be a tall order.
> 
> Andrei

That's the problem.  We ARE talking about two different things.  You are thinking -nogc should denote reference counting.  If we are talking about reference counting, then I agree with you.  However, circular references become an issue, and D code compiled this way will have to be fixed somehow to resolve this, perhaps using weak pointers as you mentioned earlier.

-Craig