BetterC code does not have a GC, and so doesn't allow using the GC. But many have correctly pointed out that not having a GC cripples CTFE. CTFE should be able to use the GC, it's a major advantage of having a GC (and cripples languages with CTFE that don't have GC).

So, making some experiments, I found it usually worked. Searching bugzilla, I found one case that didn't:

  https://issues.dlang.org/show_bug.cgi?id=20101

and fixed it:

  https://github.com/dlang/dmd/pull/14789

For those that still suffer the slings and arrows from this problem, please let me know the bugzilla issues for them.

P.S. This also applies to @nogc code - CTFE should still be able to use the GC. Isn't that cool? Destroy the question "what good a GC is in a systems programming language!"

On Saturday, 7 January 2023 at 02:09:00 UTC, Walter Bright wrote:
> BetterC code does not have a GC, and so doesn't allow using the GC. But many have correctly pointed out that not having a GC cripples CTFE. CTFE should be able to use the GC, it's a major advantage of having a GC (and cripples languages with CTFE that don't have GC).
>
> So, making some experiments, I found it usually worked. Searching bugzilla, I found one case that didn't:
>
>   https://issues.dlang.org/show_bug.cgi?id=20101
>
> and fixed it:
>
>   https://github.com/dlang/dmd/pull/14789
>
> For those that still suffer the slings and arrows from this problem, please let me know the bugzilla issues for them.
>
> P.S. This also applies to @nogc code - CTFE should still be able to use the GC. Isn't that cool? Destroy the question "what good a GC is in a systems programming language!"

Way to go! Although I deeply hate betterC, this is great! This increases a lot of potential usages on nogc code :)

On Saturday, 7 January 2023 at 02:45:16 UTC, Hipreme wrote:
> Way to go! Although I deeply hate betterC, this is great! This increases a lot of potential usages on nogc code :)

CTFE can already use GC in @nogc code since a long time ago. I don't understand what's the news and in what way does this make betterC more relevant.

On 1/6/2023 6:59 PM, Siarhei Siamashka wrote:
> CTFE can already use GC in @nogc code since a long time ago. I don't understand what's the news and in what way does this make betterC more relevant.

Fixing it for mixins is a big deal.

On Saturday, 7 January 2023 at 02:09:00 UTC, Walter Bright wrote:
> [...]
> For those that still suffer the slings and arrows from this problem, please let me know the bugzilla issues for them.
>
> [...]

These two still don’t work:

https://issues.dlang.org/show_bug.cgi?id=21492
https://issues.dlang.org/show_bug.cgi?id=21482

On Saturday, 7 January 2023 at 06:45:38 UTC, Dave P. wrote:
> On Saturday, 7 January 2023 at 02:09:00 UTC, Walter Bright wrote:
>> [...]
>> For those that still suffer the slings and arrows from this problem, please let me know the bugzilla issues for them.
>>
>> [...]
>
> These two still don’t work:
>
> https://issues.dlang.org/show_bug.cgi?id=21492
> https://issues.dlang.org/show_bug.cgi?id=21482

It seems you still have to work around these with templates. An improvement anyway because now variadics and overloads can be used (the lambda hack didn't allow that).

On Saturday, 7 January 2023 at 02:09:00 UTC, Walter Bright wrote:

> So, making some experiments, I found it usually worked. Searching bugzilla, I found one case that didn't:
>
>   https://issues.dlang.org/show_bug.cgi?id=20101
>
> and fixed it:
>
>   https://github.com/dlang/dmd/pull/14789
>

Simple test cases still don't compile:

string foo()()
{
    string a, b;
    return a ~ b;
}

enum s = foo();

./dmd -c -betterC test.d
test.d(4): Error: array concatenation of expression `a ~ b` requires the GC which is not available with -betterC

On Saturday, 7 January 2023 at 02:09:00 UTC, Walter Bright wrote:
> BetterC code does not have a GC, and so doesn't allow using the GC. But many have correctly pointed out that not having a GC cripples CTFE. CTFE should be able to use the GC, it's a major advantage of having a GC (and cripples languages with CTFE that don't have GC).
>
> So, making some experiments, I found it usually worked. Searching bugzilla, I found one case that didn't:
>
>   https://issues.dlang.org/show_bug.cgi?id=20101
>
> and fixed it:
>
>   https://github.com/dlang/dmd/pull/14789
>
> For those that still suffer the slings and arrows from this problem, please let me know the bugzilla issues for them.
>
> P.S. This also applies to @nogc code - CTFE should still be able to use the GC. Isn't that cool? Destroy the question "what good a GC is in a systems programming language!"

I have long decided that C# and Go, following the path trailed by Cedar, Modula-3 and Oberon, show how it goes.

Every time I decide to have a look at what is happening in D, most certainly there is a ongoing discussion thread about the GC.

So much discussion about systems programming and GC, while others are shipping hardware running Go and .NET workloads on bare metal, like USB Armoury and Meadow boards.

On Saturday, 7 January 2023 at 10:31:28 UTC, Paulo Pinto wrote:
> Every time I decide to have a look at what is happening in D, most certainly there is a ongoing discussion thread about the GC.
>
> So much discussion about systems programming and GC, while others are shipping hardware running Go and .NET workloads on bare metal, like USB Armoury and Meadow boards.

Although I really hate betterC, having the nogc thing is a good thing. Making everything nogc is useless though. For example, leaking GC data in a loop is not good, so for my engine I can easily check if I'm doing that and where I'm doing that. What I would prefer though would be nogc, pure and safe inference because most people hates putting all attributes to make it callable by any function.

That being said, I don't want discussions about GC unless a way to make it run on WASM or how to make it faster, that is tackling the problems right in the root.

Anyway, GC makes people productive and I believe that in 2023 it should not even be a question.