Is there some way for library authors to test whether a GC is present at compile time? @nogc just means that my code does not depend on a GC, but it doesn't tell the compiler that my code is incompatible with GC.

I want to compute pointers in a way that is not scannable by a conservative collector for performance reasons. So I need to make sure that the faster code isn't chosen when people use GC using "static if"s.

On 1/26/21 8:10 AM, Ola Fosheim Grøstad wrote:
> Is there some way for library authors to test whether a GC is present at compile time? @nogc just means that my code does not depend on a GC, but it doesn't tell the compiler that my code is incompatible with GC.
> 
> I want to compute pointers in a way that is not scannable by a conservative collector for performance reasons. So I need to make sure that the faster code isn't chosen when people use GC using "static if"s.
> 
> 
> 

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.

In that case, you can do version(D_BetterC)

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).

-Steve

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?

> 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 guess I also will find the equivalent of C++ std::trivially_copyable, std::trivially_destructible in Phobos, to figure out if memcpy is safe.

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

On Tuesday, 26 January 2021 at 16:08:15 UTC, Steven Schveighoffer wrote:
> std.traits.hasAliasing?

I guess, but it will limit me too much. I should accept Element types that manage their own memory and has pointers to sub-ojects that don't point to GC memory. But I guess that would require a language extension or I would have to establish my own protocol (basically some enum I can test for, I guesss).


> 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.

:-/

You can define a symbol that will conflict with GC and prevent linking with it.

On Wednesday, 27 January 2021 at 20:21:02 UTC, Kagamin wrote:
> You can define a symbol that will conflict with GC and prevent linking with it.

That was an interesting thought! Maybe that could be a first step.

It didn't occur to me that I could sabotage the usage of GC. :-D

You can make it opt in, it's insurance.