June 17

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.

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

June 17

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.

June 17

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 rationale is very weak. If the only use case is to support bad usage of @attribute: or @attribute {}, there is no benefit at all to this.

June 18

On Monday, 17 June 2024 at 22:01:18 UTC, Mathias Lang 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 rationale is very weak. If the only use case is to support bad usage of @attribute: or @attribute {}, there is no benefit at all to this.

I don't think so.
If a program is all @nogc except a single function (or even a unittest), using @nogc: is plausible. I wouldn't call this "bad usage".
But at the moment there is no way to mark this single test as "not @nogc". I find this situation annoying.
The same problem arises with pure:

June 19

On Monday, 17 June 2024 at 22:01:18 UTC, Mathias Lang 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 rationale is very weak. If the only use case is to support bad usage of @attribute: or @attribute {}, there is no benefit at all to this.

It’s exactly as strong or weak as adding throw as the inverse of nothrow was.

The only argument that is different between DIP 1029 and this is that throw was already a keyword whereas @gc would have to be added.

Compare that to the (hypothetical) suggestion of adding impure as a keyword to have an inverse of pure.

June 21
On 6/14/2024 9: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.
> 

I've been thinking about a `@default` attribute, which will reset the state of attributes to the defaults. This will obviate the need for @gc, @impure, @throw, and so forth.
June 22
On Saturday, 22 June 2024 at 04:37:01 UTC, Walter Bright wrote:
> I've been thinking about a `@default` attribute, which will reset the state of attributes to the defaults. This will obviate the need for @gc, @impure, @throw, and so forth.

But will bite us if we ever changing the default :-/
June 25

On Saturday, 22 June 2024 at 04:37:01 UTC, Walter Bright wrote:

>

On 6/14/2024 9: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.

I've been thinking about a @default attribute, which will reset the state of attributes to the defaults. This will obviate the need for @gc, @impure, @throw, and so forth.

It doesn’t. Having a formal name for the inverse of an attribute has several advantages over just saying “default,” e.g. the compiler today spells out @system when printing function (pointer) and delegate types. Likewise, one can declare a function (template) explicitly @system and it would allow one to be explicit about @gc things.

If anything, I’d want to see default with regards to attributes used in a block or label statement with the meaning of changing the default attributes, but not touch inference. Something like:

@nogc @safe
{
    void f() { … } // `@nogc @safe` by `@safe` `@nogc` block
    void g(T)() { … } // `@gc`/`@nogc` `@safe`/`@system` inference disabled
}
default @nogc @safe
{
    void f() { … } // `@nogc @safe` by `default @nogc @safe` block
    void g(T)() { … } // `@gc`/`@nogc` `@safe`/`@system` inference enabled
}

The default … block sets defaults. We can easily define default: and default{} to mean default @system throw @gc impure (or the module default, see below), but without an impure keyword, in a @safe pure: context, one would have to do:

default @safe pure:
…

default // idea: `default impure`, but is actually `default impure @system`, therefore ...
{
default @safe: // ... set `@safe` as default again
    …
}

to apply impure as the default. That is annoying because expressing a simple idea becomes hard. A programming language is a language to express ideas human-to-human and incidentally human-to-machine.

Applying default to a declaration directly goes against the whole idea of what a default setting is.

I also see a difference between specifying default attributes for a module versus what’s formally a part of a module (even if it happens to span the whole module). E.g.

default @safe
module m;

would differ from

module m;
default @safe:

by how function pointer and delegate types are interpreted:

module m;
@safe: // same as `default @safe:` in this example
void f(void function() callback) { }

makes typeof(&f) be void function(void function() @system) @safe, whereas

default @safe
module m;
void f(void function() callback) { }

makes typeof(&f) be void function(void function() @safe) @safe.

The type of the function parameter is @safe/@system based on the module’s default and nothing else. I suspect that making any attribute the default, higher-order functions will be a big hurdle because no matter if a the new language-level default affects parameters of function pointer / delegate types or not, things break. However, for an individual code base, changing the default for a module in this way can make sense and happen to be without issues. Making @safe the language default requires something like ADAs, but allowing for module-specified defaults is orthogonal.

1 2
Next ›   Last »