On 1/26/21 11:00 AM, Ola Fosheim Grøstad wrote:
On Tuesday, 26 January 2021 at 15:30:09 UTC, Steven Schveighoffer wrote:
The only way to ensure the GC isn't used is with betterC. Even with
@nogc tag on main, the GC could be used in static ctors, and casting
function pointers/etc.
Yes, @nogc is not strong enough... It is for a container library, so
maybe I could put test for the properties of the elements instead?
I guess I would want test if the Element type contains a pointer that
should be traced by the GC.
But how would I go about it?
std.traits.hasAliasing?
And this will only apply to templates, not to compiled code, since
compiled code already is done (and one can obviously use betterC
compiled code in normal D code).
Yes, but templates is ok, but I think Better_C is too restrictive in the
long term. So I hope there is some way for my library to figure out if
it has to care about GC for the template parameters the user provides.
I thought about it a bit more, and even this is not good enough. One can
compile a betterC library using your code, which is then used by a
GC-allocating app, which means your library is told betterC is in use
while compiling the template, but the GC is still involved.
So there doesn't seem to be a way to be sure that a pointer is not a GC
pointer.
-Steve
