The D standard library is built on GC, is that a negative or positive?

[Steven Schveighoffer]

On 12/15/22 6:04 PM, bachmeier wrote:
> On Wednesday, 14 December 2022 at 01:47:29 UTC, Steven Schveighoffer wrote:
> 
>> But if the string you give it happens to not contain a string 
>> representation of an integer, it wants to throw an exception. And the 
>> act of allocating and throwing that exception needs the GC.
>>
>> We really really need to fix it. It completely cuts the legs out of 
>> the answer "if you don't want the gc, use @nogc". If we do fix it, all 
>> these questions pretty much just go away. It goes from something like 
>> 20% of phobos being nogc-compatible to 80%.
> 
> Is avoiding the GC inside exceptions a problem that needs to be solved? 
> Maybe it is, but I don't think it's common to have a loop with millions 
> of exceptions. Perhaps the issue is that there should be a version of 
> @nogc that doesn't care about exceptions. With the current 
> implementation of exceptions, the intersection of "avoiding GC" and 
> "abusing exceptions" is almost certainly small.

Why does the quantity of exceptions matter? The point of avoiding the GC 
is to avoid the collection, which can happen with a single allocation. 
If you want to avoid the GC for specific code paths, you don't want to 
say "OK, I guess I can't parse integers in here".

Note that it's also possible to assume the GC *likely* won't get 
triggered, because an exception is very unlikely. But having a mechanism 
to ask the compiler to help prove it, which can't be used, is pretty 
frustrating.

-Steve