Looking for a Lua alternative

[Siarhei Siamashka]

On Friday, 15 December 2023 at 10:53:44 UTC, Bastiaan Veelo wrote:
> On Thursday, 14 December 2023 at 18:26:40 UTC, Siarhei 
> Siamashka wrote:
>> On Thursday, 14 December 2023 at 18:18:21 UTC, matheus wrote:
>>> Allocate();
>>> GC.disable();
>>> run_the_game();
>>> GC.enable();
>>
>> Is the `run_the_game()` part of code supposed to be annotated 
>> with the `@nogc` attribute?
>
> It depends, I guess. If it is not `@nogc` annotated, it can 
> still allocate and if it does it can run out of memory, unless 
> it calls `GC.collect` at the right moments. If it is `@nogc` 
> annotated, it cannot allocate and then the whole `GC.disable` 
> and `GC.enable` become unnecessary.

That's exactly my concern and the compiler isn't very helpful in 
this scenario.

Would it be useful to have something like `@vettedgc` attribute, 
for annotating the part of code, where each GC allocation needs 
to be pedantically reported by the compiler as a warning? And 
some sort of `@permitgc` attribute to suppress these warning in a 
few selected places inside of this code if really necessary?

I would suggest to maybe somehow differentiate between "hard" 
`@nogc` variety, where the garbage collector isn't even linked at 
all. And "soft" `@nogc` variety, where GC allocations are 
generally strongly discouraged, but allowed as explicitly 
annotated exceptions in a few selected places after careful 
review. The former is useful for hardcore bare metal embedded use 
cases and that's what the compiler supports right now. The latter 
would be maybe useful for game developers.