D Language 2.0

[Andrei Alexandrescu]

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