[First Draft] Add @gc as a Function Attribute

[jmh530]

On Monday, 17 June 2024 at 11:37:22 UTC, Quirin Schroll wrote:
> On Friday, 14 June 2024 at 19:19:15 UTC, jmh530 wrote:
>> [snip]
>>
>> The DIP makes it seem like it is an escape-hatch for @nogc. 
>> But then @nogc would no longer be providing any guarantees.
>
> You didn’t understand the DIP. It’s not an escape hatch. `@gc` 
> is just an explicit form of the default behavior allowing GC 
> allocations. You can’t call a `@gc` function from a `@nogc` 
> function, the same as you can’t call a `@system` function from 
> a `@safe` function.

I said "The DIP makes it seem like it is an escape-hatch". I 
didn't say "The DIP introduces an escape-hatch".

It's not that I didn't understand it, so much as I'm doing my 
best to try to understand what it says and coming to an 
understanding that is inconsistent with what I think you intend.

In the rationale section, you detail the motivation relating to 
the issue of dealing with adding a function that allocates with 
the GC to @nogc blocks.

You then introduce the example

```d
@nogc
{
     int[] f()     => [1]; // Error: array literal in `@nogc` 
function `f` may cause a GC allocation
     int[] g() @gc => [1]; // Okay, `g` is not `@nogc`
}
```

This makes it seem like you can have a function that may cause a 
GC allocation in a @nogc block by adding the @gc attribute. Maybe 
that's not what you intended, but you should spell it out in more 
detail if you intend something else.

If @gc means not @nogc, then how can the compiler verify that it 
can be called from a @nogc block?