D Language 2.0

[Craig Black]

"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.

-Craig