D Language 2.0

[Craig Black]

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

-Craig