Instead of using @nogc, we could have a compiler switch "warn on use of GC" which you can turn on if you like, or not, or turn on the -w switch to treat the gc warnings as errors.

On Sunday, 14 January 2024 at 09:25:18 UTC, Walter Bright wrote:
> Instead of using @nogc, we could have a compiler switch "warn on use of GC" which you can turn on if you like, or not, or turn on the -w switch to treat the gc warnings as errors.

What if you use @nogc in the hot-path but want to use gc during initialization?

On 14/01/2024 10:25 PM, Walter Bright wrote:
> Instead of using @nogc, we could have a compiler switch "warn on use of GC" which you can turn on if you like, or not, or turn on the -w switch to treat the gc warnings as errors.

We already have a way of finding out where all the GC allocations is as a compiler switch.

This does not need to be a warning.

You want the guarantee in hot loops that a GC allocation will not take place there accidentally.

The primary source of this is closure creation. Where it is being stored is not scope (such as a function parameter).

I.e. ``@localnogc`` or ``@nogc(scope)``

```d
void hot(float[] a, float b) /* @localnogc */ {
	size_t last;
	accept(() { // error: will allocate closure context with GC
		if (last > a.length)
			return float.init;
		return a[last++] + b;
	});// ok, accept uses GC, this call is not checked.
}

void accept(float delegate() del) {

}
```

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.

On Sunday, 14 January 2024 at 09:25:18 UTC, Walter Bright wrote:
> Instead of using @nogc, we could have a compiler switch "warn on use of GC" which you can turn on if you like, or not, or turn on the -w switch to treat the gc warnings as errors.

It aint broke so dont fix it.

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)

And some people who keep having to explain it to newbies apparently. But my feeling about that is that it's not that @nogc is hard to understand but that they don't understand how GC works in general.

Inference on regular non-templated functions would help a bit i think.

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.

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.

On Sunday, 14 January 2024 at 12:21:51 UTC, claptrap wrote:
> On Sunday, 14 January 2024 at 09:25:18 UTC, Walter Bright wrote:
>> Instead of using @nogc, we could have a compiler switch "warn on use of GC" which you can turn on if you like, or not, or turn on the -w switch to treat the gc warnings as errors.
>
> It aint broke so dont fix it.
>
> Nobody who uses @nogc is complaining about it. The people who are complaining are people who don't use it

+1
We use it because we have to.
When we transitionned to @nogc, only part of the code had the @nogc attribute, so how could we done that with just a switch.
When we make a @ngoc library, we can currently add a GC-using function to throw in case the no-@nogc people want to use the library...
And what happened of the promise to not break things.
I don't understand the complaints at all.