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