"Andrei Alexandrescu" <seewebsiteforem...@erdani.org> wrote in message
news:hj8gd7$2so...@digitalmars.com...
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
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
