Jump to page: 1 2
Thread overview
June 14

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.

June 15
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``.

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

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

On Friday, 14 June 2024 at 16:20:02 UTC, 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.

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

June 16

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.

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

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

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

@gc(:yes | :local)

June 16
On 16/06/2024 8:13 PM, ryuukk_ wrote:
> Why couldn't attributes accept a parameter, perhaps a flag
> 
> |@gc(:yes | :local)|

Right now we have yes/no, infer(red)/explicit bit fields for some flags.

The only attribute that we've had consistent desire to have local for is ``@nogc`` it doesn't need to be supported for all.

As positive/negative state of an annotate are both common things, it should take minimal characters to represent, in this case a single additional ``!``.

So I don't think we need to over complicate it by introducing parameters to any attributes other than for the throws set and thats only because we need to be able to represent what a value type exception style exceptional handling mechanism would be returning in the type system.
June 17

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

>

On Friday, 14 June 2024 at 16:20:02 UTC, 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.

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.

June 17

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

June 17

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

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

June 17

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.

June 17

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

>

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

@gc(:yes | :local)

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.)

« First   ‹ Prev
1 2