Edward Diener made the observation (emphasis is mine):
In my previous blog entry, I listed two reasons not to conflate the type category
with where objects of that type can be allocated, namely to let us in the future support
allocating native types on the GC heap, and CLI types on the native heap. The decision
to garbage-collect or not should not be per-type (as it was in MC++), but per-object.
To that, I should also add that "CLI types" already does not mean "garbage-collected
types." In particular, the CLI knows about two kinds of types: reference types, and
value types. First, value types are never garbage-collected in their unboxed form.
Second, nearly all programs have objects of reference and boxed value type that are
intentionally never collected because they are used right through to the termination
of the program; they are one reason why the CLI GC is generational, and why the
CLI has features for controlling whether or not such objects ever get the finalizers
run, for example.
That's possible, but in our experience so far (having tried to do it that way for
two releases now) we've found that users are far more apt to be confused by failing
to surface an important distinction. This is the balancing act of language design:
it is just as bad to fail to surface an important distinction (which creates a trap
and a usability barrier) as it is to needlessly surface a distinction that could
have been hidden from the programmer (which creates clutter and a different kind of