[ ... ]
It's still very much in a state of flux, but the last proposal I
saw provided for three cases: code which required garbage
collection, code which couldn't work with it, and code which was
garbage collection neutral. Presumably, the standard libraries,
and most third party libraries, would be designed to fall into
the last category. (Although I suspect that more than a few
implementations would offer two sets of libraries, one of which
required garbage collection, simply because something like
std::basic_string can be made a lot faster if you can count on
garbage collection being present.)
The most recent draft I've looked at on it is N2287. It fairly
specifically does NOT say you can ever depend on GC being present. The
closest it comes is a note that says [basic.stc.collect]:
[ Note: For garbage collected programs, a high quality
hosted implementation should attempt to maximize the
amount of unreachable memory it reclaims. ?end note ]
That's it. There's a lot of language to define things like what
constitutes unreachable memory. When you get down to it, however, a
large part of the idea is that the garbage collection is transparent --
which means it has no externally visible effect on the program.
I know a lot of people really want garbage collection, and I know some
smart people have really put some hard work into it -- but when you get
down to it, trying to specify GC in terms of externally visible,
required behavior is nearly impossible. There's no guarantee that any
allocation will ever succeed, and basically all GC can ever do do is
increase the chance of an allocation succeeding.
Other than that, N2287 adds some mechanisms that attempt to give you
control over whether GC is optional, required, etc. -- but with no clear
definition of what GC really does (and probably none possible) it's
pretty easy for an implementation to "conform" by saying GC is present,
but never providing a real implementation (i.e. GC is simply a NOP).
There are, of course a few real rules to be added -- basically just a
restriction against pointer swizzling, and other such things that
prevent a pointer from being recognized (well, it's not really a
restriction against it -- but the code has undefined behavior if it
attempts to dereference a pointer after it's been unrecognizable for any
period of time).
[ ... ]
The obvious intent is not too. The general philosophy of C++ is
to rule out as little as possible (and it's a philosophy which
has paid off in the long run). The issue is still under active
discussion, however, and it's hard to say exactly what the final
form will be.
At least based on the papers I've looked at so far, very little will be
ruled out in terms of implementation. At least in my view, the problem
is much more that code will be restricted without guaranteeing anything
in return. The only comfort is that the restrictions are pretty trivial.
