On Saturday, 7 September 2024 at 13:28:39 UTC, Richard (Rikki) Andrew Cattermole wrote:

import std;
void main() {
     writeln(add(3, 4));
}
@nogc int add(int x, int y) { return x+y; }

module app;
import sidero.base.console;

@safe nothrow @nogc:

void main() {
    writeln(add(3, 4)); // 7
}

int add(int x, int y) {
    return x + y;
}

On run.dlang.io:

onlineapp.d(1): Error: unable to read module `console`
onlineapp.d(1):        Expected 'sidero/base/console.d' or 'sidero/base/console/package.d' in one of the following import paths:
import path[0] = /dlang/dmd/linux/bin64/../../src/phobos
import path[1] = /dlang/dmd/linux/bin64/../../src/druntime/import

Searching on code.dlang.org: Found 0 packages. So not much of a replacement.

Some introspection:

@nogc has an unintended effect of forcing its users to do optimization in the form of using preallocated memory. Might be replicated by using IDE extensions, which could warn the user for malloc() and similar calls.

On Saturday, 7 September 2024 at 13:06:45 UTC, Lance Bachmeier wrote:

import std;
void main() {
    writeln(add(3, 4));
}
@nogc int add(int x, int y) { return x+y; }

You just don't use @nogc.
My point is that your code is already nogc. No need for an attribute.

On Sunday, 8 September 2024 at 00:10:05 UTC, Kapendev wrote:

import std;
void main() {
    writeln(add(3, 4));
}
@nogc int add(int x, int y) { return x+y; }

And if you are unsure if a function allocates with the gc, you can always test. In my experience, if you don't use the ~ operator, array literals or delegates, then you are fine.

Just an idea. As I said, I am fine with how things are now.

On Sunday, 8 September 2024 at 00:18:53 UTC, Kapendev wrote:

import std;
void main() {
    writeln(add(3, 4));
}
@nogc int add(int x, int y) { return x+y; }

@nogc is a viable option for optimizing hot paths, in some cases at least.

First you profile to find where your code is doing most of the work, then you start from the bottom by adding @nogc step by step on such performance hungry functions, it will also enforce changes to these functions from making spontaneous changes.
Sure there is also -vgc flag that will show you everything, but often only hot paths is all you need.

But like was already said people often tends to use it as a hammer to smash everything, and then they suddenly find out this does not scale or not even work, or solves the problem they never had.

On Sunday, 8 September 2024 at 00:10:05 UTC, Kapendev wrote:

Same can be said for every other attribute, let's get rid of all of them!

No of course not. We use attribute not because we can't write that code without them, but because we want the compiler to check if something doesn't unexpectedly find its way in.

With changing requirements and changing authors, it is easy for almost all of your assumptions and conventions to break. Having an attribute is so much better than having to write a comment and/or needing to be extra vigilant at code review time.

On Sunday, 8 September 2024 at 00:18:53 UTC, Kapendev wrote:

And test every function you call, and every function that function calls, and so on. And hope that nobody changes the implementation after you've checked it, etc..

On Sunday, 8 September 2024 at 09:14:21 UTC, claptrap wrote:

IFF d had a full time embedded and wasm std dev, and a backlog of bug reports shorter then 10 years long, it would be fine as they make whatever style guide changes and edge cases could be solved as they came up from real use.

Adding nogc to an existing old tech debt project is less realistic then doing an separate new std; and that new std could just be compiled with betterc