Warn about using the GC

[Richard (Rikki) Andrew Cattermole]

On 15/01/2024 2:55 AM, Alexandru Ermicioi wrote:
> On Sunday, 14 January 2024 at 13:40:11 UTC, Richard (Rikki) Andrew 
> Cattermole wrote:
>> Earlier on I considered ``@assumenogc`` instead.
>>
>> It could work, but is much more explicit in code, that probably 
>> doesn't care. Which is why this should be the default, not opt-in.
> 
> I'd prefer it to be used explicitly as with `@trusted` since you should 
> think twice before using gc, where people intend nogc. It may work as 
> you've stated only when lib dev allows it to, i.e. only when callback 
> parameter was declared with `@assumegc`.
> 
> That would allow it to be spotted easier, and allow reviewers to fuss 
> over if they prefer to.
> 
> Besides now you need to put `@nogc` on callback anyways, so changing it 
> to `@assumegc`, would be same level of pain.

I think that you might have this slightly backwards, but please do clarify.

The GC is excellent for application logic where performance does not 
matter. This makes a great default. It is how D exists, and I do not 
believe we will be changing this ever.

Disabling GC calls has a very strong compiler backed transitive 
guarantee with ``@nogc``, there are people that rely on this guarantee 
for their code and for that reason I do not believe we will ever weaken 
the transitory nature of that beyond what is provided in the arguments 
list. Especially since some people have businesses built upon it.

It is worth noting that closures when declared, will have their 
attributes inferred. You do not need to annotate ``@nogc`` on them. Such 
a guarantee when passed into a function/delegate pointer that does not 
have it, will be stripped automatically. Therefore there should not be 
any pain in such a case.

However I think the basic premise of what you are suggesting is a kind 
of informed consent towards the GC. You annotate if you use GC or not, 
and you may be callable.

During my mental experiments for such a design, I did not find any 
guarantees that would be provided by it. As such it would be a highly 
fragmentary approach to library development and would not achieve the 
desired goals but would cause unreset.

I did briefly consider a way of annotating of code that it is has been 
checked against a user identified thing manually. However I have not 
pursued it beyond that. This with ``@localnogc`` could function as you 
described in your previous post.

The only thing left to consider from your post I suppose is what would 
somebody want to review when you are calling a non-GC function from a GC 
function with a GC callback? This I cannot answer. I have not been able 
to come up with anything that would meet such a description. But I would 
welcome such a discussion!