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

[Steven Schveighoffer]

On 12/15/22 7:27 PM, bachmeier wrote:
> On Thursday, 15 December 2022 at 23:29:55 UTC, Steven Schveighoffer wrote:
>> 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".
> 
> It matters if you expect the quantity to be zero. If you've thoroughly 
> tested your code, and you're confident that the exception isn't 
> relevant, it doesn't matter. It is quite rare that `to!int` would throw 
> an exception in my code.

Totally agreed. But one to!int inside a big function makes it so it 
can't be @nogc. You might want the @nogc for other reasons. It just 
strikes me as limiting that converting string to int cancels the ability 
to use @nogc at all.

> 
>> 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.
> 
> Those wanting that could continue to use the current @nogc. If they're 
> fine with a one in a million chance of a collection, they don't need 
> that kind of proof, and they could use @nogc right now with the 80% of 
> Phobos you have cited.
> 

Maybe you misunderstood what I said. 20% of phobos is usable with @nogc 
(not tested, but that's my expectation). Fixing exceptions so they don't 
use the GC would be a single thing that flips that 20% to 80%.

-Steve