[First Draft] Add @gc as a Function Attribute

[Quirin Schroll]

On Friday, 14 June 2024 at 16:38:09 UTC, Richard (Rikki) Andrew 
Cattermole wrote:
> On 15/06/2024 4:20 AM, Quirin Schroll wrote:
>> Permalink: 
>> https://github.com/Bolpat/DIPs/blob/8a26c2545b0a6926d799e9d8dc8c3662e58d516b/DIPs/DIP-4NNN-QFS.md
>> 
>> ---
>> 
>> **Abstract:** Add `@gc` as a new function attribute that acts 
>> as the inverse of the `@nogc` attribute.
>
> At some point I wanted to do a DIP that ensured all attributes 
> had a positive form, a common negated syntax ``@!identifier``, 
> changed throwing to be set based ``@throws(...)`` and add 
> ``@notls``, ``@localnogc``.

This is like 4 orthogonal proposals.

I have no clue what `@notls` would do exactly.

If anything, `localnogc` should be a pragma (probably named 
differently) as it provides no actual guarantees. I know from 
other posts that its intention is to particularly guarantee that 
array literals and closures present in the function block aren’t 
GC-allocated. It means nothing for the caller of a function, it 
only means something for the implementer. The question if a 
closure is allocated or not is practically the same if the 
compiler recognizes your specific case. It does not make sense as 
a function attribute as a caller need not know about it.

Set-based exception specifications are controversial. I’m not 
sure if they’re a win or not, but this proposal is completely 
unrelated. Zig has them, but Zig has return-based exceptions, 
where anything other than a white list of possible exceptions is 
hard to imagine. Java’s are considered a failure and C++ removed 
them.

> So I'm in support of this proposal, but it doesn't go anywhere 
> near where it needs to in terms of scope.

Yes, the scope of this DIP is to be small and uncontroversial.

> You're welcome to do the proposal instead as I'm busy on other 
> things atm if it interests you.

The `pragma(nogcClosures)` and `pragma(nogcArrayLiterals)` should 
not even require a DIP.

I cannot write anything about `notls` as I don’t know what it 
means.

I can write a DIP for a complete revision of guarantee-making 
attributes, and that would include things like attribute 
`inout`s/attribute variables. I once wrote a DIP draft for 
something like that; ADAs comes close. My takeaway is that very 
ambitious DIPs generally make it nowhere.

My sense is: Let’s first add contravariant inverses 
(guarantee-absence indicating) for `@nogc` and `pure`. Those 
solve a very basic non-orthogonality issue. Then let’s talk about 
guarantee-making attributes taking booleans or variables for 
guarantee-making attributes.