Compile time check for GC?
Steven Schveighoffer
schveiguy at gmail.com
Tue Jan 26 16:08:15 UTC 2021
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
More information about the Digitalmars-d-learn
mailing list