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.

On Friday, 14 June 2024 at 16:20:02 UTC, Quirin Schroll wrote:

The DIP makes it seem like it is an escape-hatch for @nogc. But then @nogc would no longer be providing any guarantees.

On Friday, 14 June 2024 at 16:38:09 UTC, Richard (Rikki) Andrew Cattermole wrote:

Why couldn't attributes accept a parameter, perhaps a flag

@gc(:yes | :local)

On Friday, 14 June 2024 at 19:19:15 UTC, jmh530 wrote:

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.

On Friday, 14 June 2024 at 16:38:09 UTC, Richard (Rikki) Andrew Cattermole wrote:

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.

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

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 inouts/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.

On Monday, 17 June 2024 at 11:37:22 UTC, Quirin Schroll wrote:

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

@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?

On Monday, 17 June 2024 at 13:02:12 UTC, jmh530 wrote:

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.

On Sunday, 16 June 2024 at 08:13:33 UTC, ryuukk_ wrote:

Attributes taking booleans would be a separate DIP. As I wrote in my answer to Rikki, local nogc should not be an attribute at all.

C++ made noexcept take a boolean. C++ also made noexcept a unary operator that returns a boolean if the expression inside uses only noexcept stuff.

D could easily do the same with nothrow and pure (as those are first-class keywords). It makes less sense for @safe (a program is supposed to be UB-free anyways), but it would make sense for @nogc.
I don’t think D would be clever to follow C++’s syntax with a prefix operator. My preferred syntax would be postfix is pure, is nothrow, is @nogc, and yes, even is @safe. Those would operate on types, though, meaning you’d have to write typeof({ expression; }) is @nogc. The typeof returns a function pointer or delegate type which has attributes inferred and those attributes can be queried using the new syntax.

You could use these together:

void higherOrderFunction(DG)(scope DG callback) @safe(DG is @safe) @nogc(DG is @nogc)
{ … }

As for the query for member function attributes that are also type qualifiers, I’d suggest a syntax similar to the one I proposed in Issue 20010): DG is ...const.

For example, a template could have an if (DG is ... const pure) restriction so that it’s guaranteed the callback’s results can be cached. (If a delegate isn’t const it can maintain state in its context, and if it’s not pure, it can maintain state globally.)