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.
Thread overview | |||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
June 14 [First Draft] Add @gc as a Function Attribute | ||||
---|---|---|---|---|
| ||||
Permalink: https://github.com/Bolpat/DIPs/blob/8a26c2545b0a6926d799e9d8dc8c3662e58d516b/DIPs/DIP-4NNN-QFS.md Abstract: Add |
June 15 Re: [First Draft] Add @gc as a Function Attribute | ||||
---|---|---|---|---|
| ||||
Posted in reply to Quirin Schroll | 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 Re: [First Draft] Add @gc as a Function Attribute | ||||
---|---|---|---|---|
| ||||
Posted in reply to Quirin Schroll | 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 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 Re: [First Draft] Add @gc as a Function Attribute | ||||
---|---|---|---|---|
| ||||
Posted in reply to Richard (Rikki) Andrew Cattermole | 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 At some point I wanted to do a DIP that ensured all attributes had a positive form, a common negated syntax 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
|
June 16 Re: [First Draft] Add @gc as a Function Attribute | ||||
---|---|---|---|---|
| ||||
Posted in reply to ryuukk_ | 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 Re: [First Draft] Add @gc as a Function Attribute | ||||
---|---|---|---|---|
| ||||
Posted in reply to jmh530 | 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 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. |
June 17 Re: [First Draft] Add @gc as a Function Attribute | ||||
---|---|---|---|---|
| ||||
Posted in reply to Richard (Rikki) Andrew Cattermole | 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 At some point I wanted to do a DIP that ensured all attributes had a positive form, a common negated syntax This is like 4 orthogonal proposals. I have no clue what If anything, 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 I cannot write anything about I can write a DIP for a complete revision of guarantee-making attributes, and that would include things like attribute My sense is: Let’s first add contravariant inverses (guarantee-absence indicating) for |
June 17 Re: [First Draft] Add @gc as a Function Attribute | ||||
---|---|---|---|---|
| ||||
Posted in reply to Quirin Schroll | 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. 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
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 Re: [First Draft] Add @gc as a Function Attribute | ||||
---|---|---|---|---|
| ||||
Posted in reply to jmh530 | 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". |
June 17 Re: [First Draft] Add @gc as a Function Attribute | ||||
---|---|---|---|---|
| ||||
Posted in reply to ryuukk_ | On Sunday, 16 June 2024 at 08:13:33 UTC, ryuukk_ wrote: >Why couldn't attributes accept a parameter, perhaps a flag
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 D could easily do the same with You could use these together:
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): For example, a template could have an |