D Language 2.0

[Andrei Alexandrescu]

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