On Friday, 20 January 2023 at 01:45:31 UTC, Walter Bright wrote:
>> void process(void delegate() userData) @nogc {}
>
> If process calls userData, then that is as it should be.

Ideally, you'd be able to say `process` inherits the nogc-ness of `userData`.

> userData is just being "passed through" and not called, then the easiest workaround is to cast it to something innocuous, or use a union.

But this is also a major pain. D's attributes are one of the biggest misses of the language.

On Thu, Jan 19, 2023 at 05:45:31PM -0800, Walter Bright via Digitalmars-d wrote:
> On 1/19/2023 5:14 AM, Adam D Ruppe wrote:
> > So if someone in a library wrote
> > 
> > void process(void delegate() userData) @nogc {}
> > 
> > it is going to force userData to be nogc regardless of their own desires.
> 
> If process calls userData, then that is as it should be. If userData is just being "passed through" and not called, then the easiest workaround is to cast it to something innocuous, or use a union.

This is a flaw in the language: there is no way to express that `process`'s attributes inherit from the passed-in delegate.  This has been a pain point for years.

The basic idea is that we want to ensure that the body of `process`, aside from the call(s) to userData, is pure/@nogc/@safe/etc., but we don't want to prevent the caller from passing an impure/GC/@system/etc. delegate (because it doesn't matter to the internal workings of `process`).  This makes `process` usable from both GC and @nogc code: if the caller is @nogc, then it must pass in a @nogc delegate.  But if the caller is GC allocating, then an allocating delegate is permitted, since the caller is already non-@nogc so a non-@nogc delegate will not change anything.

If we don't do it this way, there will always be a case that doesn't work.  If we make the delegate parameter @nogc, then non-@nogc code will not be able to pass in a delegate that GC-allocates.  If OTOH we try to be inclusive and make the delegate parameter unmarked, then @nogc code will not be able to call `process`.  The only workaround in this case is to invent `processWithGC` and `processWithNoGC` (because we cannot overload on @nogc/non-@nogc) with identical function bodies.  This is a waste, since the function bodies can be merged without changing any semantics at all.

The same argument applies to the other attributes: pure, @safe, nothrow, etc..


T

-- 
He who sacrifices functionality for ease of use, loses both and deserves neither. -- Slashdotter

On 1/19/2023 6:18 PM, Adam D Ruppe wrote:
> Ideally, you'd be able to say `process` inherits the nogc-ness of `userData`.

That's exactly what template attribute inference does.

On 1/19/2023 7:19 PM, H. S. Teoh wrote:
> This is a flaw in the language: there is no way to express that
> `process`'s attributes inherit from the passed-in delegate.  This has
> been a pain point for years.

void process()(void delegate() userData) {}

Consider:

 void delegate() dg;

 // no error
 void process(void delegate() userData) @nogc { dg = userData; }

 // Error: `@nogc` function `process2` cannot call non-@nogc delegate `userData`
 void process2(void delegate() userData) @nogc { userData(); }

If process() is made into a template, it will "inherit" @nogc based on whether the delegate is called or not.

On 1/19/2023 4:31 PM, H. S. Teoh wrote:
> Nobody wants to deal with attribute soup

<wry>
ImportC has to deal with the attribute soup of extensions added to various C compilers, all different. D is not so bad!
</wry>

On Thu, Jan 19, 2023 at 07:41:02PM -0800, Walter Bright via Digitalmars-d wrote:
> On 1/19/2023 7:19 PM, H. S. Teoh wrote:
> > This is a flaw in the language: there is no way to express that `process`'s attributes inherit from the passed-in delegate.  This has been a pain point for years.
> 
> void process()(void delegate() userData) {}

Code:

````
void process()(void delegate() cb) { cb(); }

void gcFunc() {
	int[] a;
	process({ a = new int[10]; });
}

void nogcFunc(void delegate() @nogc cb) @nogc {
	process(cb);
}
````

Compiler output:

````
/tmp/test.d(9): Error: `@nogc` function `test.nogcFunc` cannot call non-@nogc function `test.process!().process`
````

Nope, doesn't work.


T

-- 
Obviously, some things aren't very obvious.