www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Warn about using the GC

reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 14
next sibling parent reply Daniel N <no public.email> writes:
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?
Jan 14
next sibling parent reply Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Sunday, 14 January 2024 at 09:44:23 UTC, Daniel N 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.


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


Too bad that Walter is most likely already fixated on his own 
idea and is in a "tunnel vision" mode, turning a blind eye on 
real practical use cases. Now he will defend his contraption to 
the bitter end. Don't expect him to pay any attention to the 
opinion of lowly plebeians. We are only allowed to cheer on him 
and praise his great talent.
Jan 14
next sibling parent reply Sergey <kornburn yandex.ru> writes:
On Sunday, 14 January 2024 at 10:49:44 UTC, Siarhei Siamashka 
wrote:

 Too bad that Walter is most likely already fixated on his own 
 idea and is in a "tunnel vision" mode, turning a blind eye on 
 real practical use cases. Now he will defend his contraption to 
 the bitter end. Don't expect him to pay any attention to the 
 opinion of lowly plebeians. We are only allowed to cheer on him 
 and praise his great talent.


more users for OpenD… so the transition may become the reality..
Jan 14
parent claptrap <clap trap.com> writes:
On Sunday, 14 January 2024 at 12:19:12 UTC, Sergey wrote:

 On Sunday, 14 January 2024 at 10:49:44 UTC, Siarhei Siamashka 
 wrote:

 Too bad that Walter is most likely already fixated on his own 
 idea and is in a "tunnel vision" mode, turning a blind eye on 
 real practical use cases. Now he will defend his contraption 
 to the bitter end. Don't expect him to pay any attention to 
 the opinion of lowly plebeians. We are only allowed to cheer 
 on him and praise his great talent.


 more users for OpenD… so the transition may become the reality..


Except they seem even more keen on killing  nogc.
Jan 14
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On Sunday, 14 January 2024 at 10:49:44 UTC, Siarhei Siamashka 
wrote:


 Too bad that Walter is most likely already fixated on his own 
 idea and is in a "tunnel vision" mode, turning a blind eye on 
 real practical use cases. Now he will defend his contraption to 
 the bitter end. Don't expect him to pay any attention to the 
 opinion of lowly plebeians. We are only allowed to cheer on him 
 and praise his great talent.


I'm really getting sick of this kind of nonsense. Disagree all 
you want, but leave insults out of it. I'm not deleting this post 
because I'm leaving it as a warning: anymore silliness like this 
is getting deleted, and any person who does it more than once is  
going on the moderation list.
Jan 14
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/14/2024 1:44 AM, Daniel N 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.


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



The choices are:

1. throw -wgc switch and get a warning for every use of the GC

2. -wgc -w and get errors for every use of the GC

3. compile the gc and non-gc modules separately, using the warning switches for 
the latter

4. disable GC collections on the hot path with GC.disable()/GC.enable()

5. use  nogc and transitively prevent any GC use at all on such functions

6. forcibly cast away  nogc and use the GC anyway

Surely one of those will work for you!
Jan 14
parent Daniel N <no public.email> writes:
On Sunday, 14 January 2024 at 18:58:11 UTC, Walter Bright wrote:

 On 1/14/2024 1:44 AM, Daniel N 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.


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



 The choices are:

 1. throw -wgc switch and get a warning for every use of the GC

 2. -wgc -w and get errors for every use of the GC

 3. compile the gc and non-gc modules separately, using the 
 warning switches for the latter

 4. disable GC collections on the hot path with 
 GC.disable()/GC.enable()

 5. use  nogc and transitively prevent any GC use at all on such 
 functions

 6. forcibly cast away  nogc and use the GC anyway

 Surely one of those will work for you!


Yes, I use 5 and it works great thanks! I was under the 
impression that you considered removing  nogc, glad that wasn't 
the case.
Jan 14
prev sibling next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
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.
Jan 14
parent reply claptrap <clap trap.com> writes:
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.



 Jan 14



  parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


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.



 Jan 14



 next sibling parent  claptrap <clap trap.com>  writes:


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.



 Jan 14



prev sibling  parent reply Alexandru Ermicioi <alexandru.ermicioi gmail.com>  writes:


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.



 Jan 14



 next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


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.



 Jan 14



  parent reply Alexandru Ermicioi <alexandru.ermicioi gmail.com>  writes:


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.



 Jan 14



  parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


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!



 Jan 14



  parent  Alexandru Ermicioi <alexandru.ermicioi gmail.com>  writes:


On Sunday, 14 January 2024 at 15:40:22 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

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


Sorry, I've reread entire thread, and it seems my suggestion is 
not related to what you've proposed with  localnogc, it is 
related to another problem with delegate callbacks, where you 
need to mark them  nogc to be called in  nogc function.

So to make things clear about what I suggested:
```d
void perform() {
     acceptDelegateWithGc(() {
         Object obj = new Object();
         return obj;
     });

     acceptNoGcDelegatesOnly(() {
         Object obj = new Object();
         return obj;
     }); // This fails since only nogc delegates are allowed

     acceptNoGcDelegatesOnly(()  trustedgc {
         Object obj = new Object();
         return obj;
     }); // This will work since delegate is marked with 
trustedgc, and therefore user knows whats he's doing when a nogc 
function calls a method that uses gc.
}

void acceptDelegateWithGc(Object delegate()  trustedgc create) 
 nogc {
	create();
}

void acceptNoGcDelegatesOnly(Object delegate()  nogc create) 
 nogc {
     create();
}
```

In your hot path case, ` trustedgc` functionality might be used, 
if it was possible to put it on statement level like this:
```d
void hot(float[] a, float b)  nogc {
	size_t last;
	float delegate() dg = () { // error: will allocate closure 
context with GC
		if (last > a.length)
			return float.init;
		return a[last++] + b;
	};

	 trustedgc accept(dg); // ok, accept uses GC, this call is not 
checked.
}
```
This example is similar to a topic that was ongoing about 
 trusted statement blocks, which I hope would be revisited in 
future and implemented.

Best regards,
Alexandru.



 Jan 14



prev sibling next sibling parent reply Guillaume Piolat <first.name gmail.com>  writes:


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.



 Jan 14



  parent  Paolo Invernizzi <paolo.invernizzi gmail.com>  writes:


On Sunday, 14 January 2024 at 13:48:14 UTC, Guillaume Piolat 
wrote:

 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.


+1, explicit is better then implicit



 Jan 14



prev sibling  parent  cc <cc nevernet.com>  writes:


On Sunday, 14 January 2024 at 13:32:14 UTC, 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.


I've wanted something like this for a while.  An 
 IAcknowledgeTheGCMayBeUsedHere (brevify this).  I experimented a 
bit (for fun) with making a locking GC that required deliberate 
unlocking prior to any attempt to allocate but solving the 
recursion problem made it stop being fun.



 Jan 18



prev sibling  parent reply claptrap <clap trap.com>  writes:


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.



 Jan 14



 next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


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.



 Jan 14



  parent reply claptrap <clap trap.com>  writes:


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.



 Jan 14



  parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


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.



 Jan 14



 next sibling parent reply Nickolay Bukreyev <buknik95 ya.ru>  writes:


On Sunday, 14 January 2024 at 12:47:47 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

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


Sounds reasonable. I guess it can work fine… until you wrap that 
delegate in a struct. Then you are out of luck, just like you are 
now. I suppose to solve this in a general case, you need to 
reinvent Rust.


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


Just curious, why 24? +/- nothrow, +/- pure, +/-  nogc, 
 safe/ system—that’s _only_ 16. You can cut it down to 8 if you 
always require  safe (callers will have to provide a  trusted 
callback).



 Jan 14



  parent  "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


On 15/01/2024 3:03 AM, Nickolay Bukreyev wrote:

     This makes it so things like |opApply|, only need one overload, not
     say 24 of them to handle all the different combinations of attributes.
 
 Just curious, why 24? +/- nothrow, +/- pure, +/-  nogc, 
  safe/ system—that’s /only/ 16. You can cut it down to 8 if you always 
 require  safe (callers will have to provide a  trusted callback).


I ran a permutation on it a couple of days ago. Might not be too accurate.

But it is still a significantly larger number than 1 ;)



 Jan 14



prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch>  writes:


On 1/14/24 13:47, Richard (Rikki) Andrew Cattermole wrote:

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


Having this be the default is mutually exclusive with me considering the 
mechanism at all sane.



 Jan 14



  parent  "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


On 15/01/2024 4:36 AM, Timon Gehr wrote:

 On 1/14/24 13:47, Richard (Rikki) Andrew Cattermole wrote:

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


 
 Having this be the default is mutually exclusive with me considering the 
 mechanism at all sane.


I would be open to discussing presets for such a design, the reason I 
want it to be the default is it would be quite common to want this and 
it could be a bit of a pain to write it out often.



 Jan 14



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 1/14/2024 4:47 AM, Richard (Rikki) Andrew Cattermole wrote:

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


The trouble with having a nogc function calling a gc delegate is it makes the 
nogc function a gc function. (If the nogc function does not actually call the
gc 
delegate, but just stores it somewhere, that works fine.) If the nogc was 
silently removed, wouldn't that be very surprising behavior?

There is another way, though. In  system code, the gc delegate can be forcibly 
cast to be  nogc (as far as the type system is concerned - it doesn't change
the 
behavior of the delegate).

Such forcible casting can be done with any of the attributes. However, as this 
subverts the type system, the correctness of it would be entirely up to the
user.

D has overrides like this because it's a systems programming language.



 Jan 14



  parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


On 15/01/2024 8:23 AM, Walter Bright wrote:

 On 1/14/2024 4:47 AM, Richard (Rikki) Andrew Cattermole wrote:

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


 
 The trouble with having a nogc function calling a gc delegate is it 
 makes the nogc function a gc function. (If the nogc function does not 
 actually call the gc delegate, but just stores it somewhere, that works 
 fine.) If the nogc was silently removed, wouldn't that be very 
 surprising behavior?


I think that we are looking at this inversely to each other.

Storing such a function pointer is itself a big problem, for instance it 
could create a time bomb that you cannot predict. But calling it has no 
direct program security issues (actual term in type theory!).

`` nogc`` doesn't affect codegen. But when it gets called on say a 
non-registered thread, could crash the program.

So as long as the caller is still in the call stack while the `` nogc`` 
code has access to it, is perfectly fine from a code security standpoint.

Whilst code security isn't a concern, performance could be. It is up to 
the caller to ensure GC is disabled if it needs to be. This may be the 
primary side effect that could be surprising. Which of course could be 
determined by using a profiler.

So in other words, the worst case scenario for calling it means you need 
to use a profiler if you care about it being slow. Which is already the 
recommended course of action.

On the other hand, storing it has as its worse case scenario program 
termination and data corruption.

As for is this surprising? Think of it this way. The caller doesn't have 
a guarantee. It does not care if what it calls has it. So why should the 
compiler create an error for something the caller never cared about in 
the first place when it could be removed?


 There is another way, though. In  system code, the gc delegate can be 
 forcibly cast to be  nogc (as far as the type system is concerned - it 
 doesn't change the behavior of the delegate).
 
 Such forcible casting can be done with any of the attributes. However, 
 as this subverts the type system, the correctness of it would be 
 entirely up to the user.
 
 D has overrides like this because it's a systems programming language.


Correctness is built upon the ability to reason the logic about something.

Casting removes the ability to reason, therefore correctness goes away too.

However, if we instead make the compiler smarter and give it the ability 
to reason the removal of guarantees, now we get to keep correctness 
whilst making the code much easier to work with.

Guarantees can be removed, they cannot be added without a proof.



 Jan 14



  parent  Zoadian <no no.no>  writes:


On Sunday, 14 January 2024 at 19:53:21 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 There is another way, though. In  system code, the gc delegate 
 can be forcibly cast to be  nogc (as far as the type system is 
 concerned - it doesn't change the behavior of the delegate).




yes, that way my idea too, but as tg pointed out to me, the  nogc 
function could store the delegate somewhere and another  nogc 
would then be able to access it.
you this only works if you can ensure nothing escapes the 
function.



 Jan 14



prev sibling  parent  Guillaume Piolat <first.name gmail.com>  writes:


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.



 Jan 14