Discussion about deprecating @nogc and workarounds

[evilrat]

On Sunday, 8 September 2024 at 00:18:53 UTC, Kapendev wrote:
> On Sunday, 8 September 2024 at 00:10:05 UTC, Kapendev wrote:
>> On Saturday, 7 September 2024 at 13:06:45 UTC, Lance Bachmeier 
>> wrote:
>>> On Saturday, 7 September 2024 at 08:05:10 UTC, Kapendev wrote:
>>>
>>>> BetterC is weird, but it does do something. If `@nogc` were 
>>>> to be removed, BetterC could act as a replacement for those 
>>>> who want to avoid using the gc and enforce that at compile 
>>>> time.
>>>
>>> How do you replace this code with BetterC? Answer: You don't.
>>>
>>> ```
>>> import std;
>>> void main() {
>>>     writeln(add(3, 4));
>>> }
>>> @nogc int add(int x, int y) { return x+y; }
>>> ```
>>>
>>> The use cases of @nogc and BetterC are very different. With 
>>> BetterC you lose classes, dynamic arrays, and associative 
>>> arrays, among other things.
>>
>> You just don't use `@nogc`.
>> My point is that your code is already nogc. No need for an 
>> attribute.
>
> 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.

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