"Andrei Alexandrescu" <seewebsiteforem...@erdani.org> wrote in message
news:hj7vnu$200...@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
