[First Draft] Add @gc as a Function Attribute

[Quirin Schroll]

On Monday, 17 June 2024 at 13:36:25 UTC, jmh530 wrote:
> On Monday, 17 June 2024 at 13:10:16 UTC, Dom DiSc wrote:
>> On Monday, 17 June 2024 at 13:02:12 UTC, jmh530 wrote:
>>> If @gc means not @nogc, then how can the compiler verify that 
>>> it can be called from a @nogc block?
>>
>> A block is nothing. A block cannot call anything, it's just a 
>> kind of namespace, meaning the same as declaring every 
>> function within it as "@nogc".
>> Of course @nogc functions _cannot_ call a function marked as 
>> @gc.
>
> My point is that the current behavior is that you know that 
> every function within `@nogc {}` does not allocate with the GC. 
> Under this DIP, that's no longer guaranteed. So fine, it's not 
> an "escape-hatch" per se, but it means that when you see `@nogc 
> {}` or `@nogc:` it won't mean what it meant before.

It’s similar to how `@safe:` and `@safe{}` don’t mean every 
function that follows is `@safe` because there can be `@system` 
or `@trusted` functions, and for `nothrow:`, while not 
implemented, the DIP adding `throw` as its inverse has been 
accepted. The general consensus is that guarantee-making 
attributes (`@safe`, `pure`, `nothrow`, and `@nogc`) all should 
have inverses, and the only question is, what syntax they’ll 
have. This is answered for two of them already (`@system` and 
`throw`); this DIP answers it for the one of the two remaining 
ones for which is very easy: `@gc`.

> At the very least, if I can misunderstand it, then others could 
> too.

It seems you didn’t actually misunderstand it, I just 
misunderstood you when you used the term _escape-hatch_ because 
an example of what I consider an escape-hatch is `@trusted`. I 
thought, you thought `@gc` would be the `@trusted` equivalent of 
`@nogc`, which it’s definitely not supposed to be.