On 15/01/2024 1:25 AM, claptrap wrote:
> On Sunday, 14 January 2024 at 09:45:49 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> On 14/01/2024 10:25 PM, Walter Bright wrote:
>>>
>> ```
>>
>> The transitive nature of ``@nogc`` where it checks function calls is the only behavior that needs to be disabled. Everything else is good for such an addition. Although AA mutation and ``.length =`` should probably be kept. Too easy to do them without realizing it.
>>
>> The goal here is to prevent unnecessary work, that is almost certain to have been done by accident.
> 
> I couldnt disagree more. That's just one use case, my use case, and anyone doing real time code, is we want to be sure there's no GC calls anywhere in the call graph. It's not just the odd hot loop.
> 
> @nogc not being transitive would be like @safe not being transitive, it would be useless for me.

I am not suggesting modifying ``@nogc``.

It works as required as-is.

But it is not a complete solution that is suitable for all scenarios.

This is not an either/or situation. We can have both solutions as different attributes.

On Sunday, 14 January 2024 at 12:29:26 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 15/01/2024 1:21 AM, claptrap wrote:
>> Nobody who uses @nogc is complaining about it. The people who are complaining are people who don't use it, they are complaining because it puts extra burden on them to support it. Or it's causing fragmentation. (Thats my impression anyway)
>
> I have over 100k LOC annotated with ``@nogc``. That is also -betterC.
>
> I am complaining.
>
> I also want contract invalidation to help make the transition for callbacks much more seemless to remove the perceived fragmentation.

I actually dont know what that means.

On Sunday, 14 January 2024 at 12:32:26 UTC, Richard (Rikki) Andrew Cattermole wrote:
>
>
>
> I am not suggesting modifying ``@nogc``.
>
> It works as required as-is.
>
> But it is not a complete solution that is suitable for all scenarios.
>
> This is not an either/or situation. We can have both solutions as different attributes.

Ah OK sorry I misread your post.

On 15/01/2024 1:43 AM, claptrap wrote:
> On Sunday, 14 January 2024 at 12:29:26 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> On 15/01/2024 1:21 AM, claptrap wrote:
>>> Nobody who uses @nogc is complaining about it. The people who are complaining are people who don't use it, they are complaining because it puts extra burden on them to support it. Or it's causing fragmentation. (Thats my impression anyway)
>>
>> I have over 100k LOC annotated with ``@nogc``. That is also -betterC.
>>
>> I am complaining.
>>
>> I also want contract invalidation to help make the transition for callbacks much more seemless to remove the perceived fragmentation.
> 
> I actually dont know what that means.


```d
void func(void delegate() @nogc del) @nogc;
```

Basically if you pass in a delegate that does not have ``@nogc``, the ``@nogc`` on the function gets removed.

The function body will of course be typed checked as if it did have ``@nogc``.

I want this to be the default, although Timon wants it to be much more configurable so you can pick and choose per parameter (again not mutually exclusive things!).

This makes it so things like ``opApply``, only need one overload, not say 24 of them to handle all the different combinations of attributes.

On Sunday, 14 January 2024 at 12:32:26 UTC, Richard (Rikki) Andrew Cattermole wrote:
>
> But it is not a complete solution that is suitable for all scenarios.
>
> This is not an either/or situation. We can have both solutions as different attributes.

Perhaps there should be a `@trustedgc`, similar to what`@trusted` is in safe system?
That would fix callback issue.

Best regards,
Alexandru.

On 15/01/2024 2:32 AM, Alexandru Ermicioi wrote:
> On Sunday, 14 January 2024 at 12:32:26 UTC, Richard (Rikki) Andrew Cattermole wrote:
>>
>> But it is not a complete solution that is suitable for all scenarios.
>>
>> This is not an either/or situation. We can have both solutions as different attributes.
> 
> Perhaps there should be a `@trustedgc`, similar to what`@trusted` is in safe system?
> That would fix callback issue.
> 
> Best regards,
> Alexandru.

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.

On Sunday, 14 January 2024 at 13:32:14 UTC, Alexandru Ermicioi wrote:
>
> Perhaps there should be a `@trustedgc`, similar to what`@trusted` is in safe system?
> That would fix callback issue.
>
> Best regards,
> Alexandru.

In favor of this.

In the other thread Walter's solution is to write a delegate that uses no GC but isn't marked @nogc. This is were such a attribute could intervene.

It would be a nice symmetry with @safe/@trusted/@system if we had @nogc/@trustedgc/@gc but then perhaps not the mental load most people want ouf ot stuff they don't care about. But if I don't care about @safe, @trusted helps me a lot more.

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.