named arguments, string interpolation, please stop.

[Timon Gehr]

On 1/11/24 22:37, Walter Bright wrote:
> On 1/11/2024 1:18 PM, DrDread wrote:
>> this is discarding the use case that you want to mark only parts of 
>> your codebase nogc, but enforce it'S really nogc. we do use some 
>> realtime threads, but the rest off the app is @gc.
> 
> This subthread suggests to me that the problem with @nogc is it works.
> ...

It does not work. There are two options:

- Mark the function and callback `@nogc`, then GC users cannot use your 
library.
- Mark the function and callback not `@nogc`, then `@nogc` users cannot 
use your library.

There are two options and both are wrong. There is no right answer 
except to accept that `@nogc` actually does not work for library 
writers, and neither do the other attributes.

> It reminds me of a similar debate when we added `const` to the type 
> system. Unlike C++, const in D is ruthlessly enforced. People wanted 
> something called "logical const" where some construct pretends to be 
> const when it was actually being mutated.
> 
> Logical const code cannot take advantage of it being const because it 
> isn't constant.
> 
> I don't see much utility in a "logical @nogc" that allows using the gc 
> anyway.
> 
> If you want to use the gc, don't use @nogc.

I do not use `@nogc`. As a result some of my code is liable to memory 
leaks due to bad escape analysis and I am having a productivity headache 
when I have to interface with `@nogc` library code. So not using `@nogc` 
is also bad. I use `const` only for POD data.