An important potential change to the language: transitory ref
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Fri Mar 19 19:56:59 PDT 2010
Hello,
Walter and I are mulling over an idea that may turn out to be extremely
interesting for D.
Consider the following desideratum: D is a garbage-collected language,
but we want to be able to define "completely encapsulated" types. That
means types that never escape pointers to their internal data. If we
manage to do so, then the type can manage memory any way it desires.
Consider the case of a simple container, e.g. an array. If we manage to
convince the array to never "leak" a reference to an element, the array
is free to deallocate memory as it wishes.
One way to achieve that is by simply having the array type return
rvalues. That is (stylized code below for a type Array!T) instead of:
ref T opIndex(size_t index);
we'd have
T opIndex(size_t index);
and so on. That way nobody can escape a pointer to stuff pointing into
the array, so the array is safe and can reallocate memory whenever it
wishes without fearing that someone has squirreled a pointer to its buffer.
I'm encouraged that Scott Meyers' Effective C++ topic 'Avoid returning
"handles" to internal data' talks essentially about that.
Of course, the problem is that you now can't change stuff inside the
array. Also there is an efficiency issue.
So I was thinking of the following: how about still returning a
reference, but define a rule in the language that references can't
escape - you can't take their address and squirrel it away; the only
thing you can do is use them right on the spot or pass them down to
functions.
Essentially that means: "I'm giving you the address of the object, but
in a scoped manner - there's nothing you can do to save it beyond the
current expression."
To clarify, for an Array!T object, you can do:
arr[5] = obj;
but you can't do:
T* p = & arr[5];
The former uses the reference anonymously right there, and the latter is
verboten because it could potentially escape "p" outside the current
expression, and an array resize would leave p dangling.
Are we hamstringing the language in a way that would disable important
idioms?
Thanks,
Andrei
More information about the Digitalmars-d
mailing list