Craig Black wrote:
"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.
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
