Discussion about deprecating @nogc and workarounds

[monkyyy]

On Monday, 9 September 2024 at 16:00:47 UTC, Dukc wrote:
> solidstate1991 kirjoitti 6.9.2024 klo 12.37:
>> A lot of people are arguing (especially on Discord) that 
>> `@nogc` should be discarded entirely in favor of betterC.
>> 
>> [snip]
>
> Putting my thoughts without having looked at other replies 
> first. No idea whether I'll go along with or against with what 
> most have written.
>
> Of these two, my gut reaction it's betterC that should (mostly) 
> go. It is far better for the language to be pay-as-you-go. If 
> not using non-shared static variables and not starting threads, 
> the langauge shouldn't (attempt to) link in threading from the 
> runtime. If not using exceptions, exception throwing/catching 
> shouldn't be linked in. And so on.
>
> For the most part, simply not using the D-specific 
> functionality would be equal to betterC in this scheme. There 
> are some exceptions to this rule. For example, assertions 
> normally throw an error on failure instead of just aborting, 
> and a header-only vanilla D library probably needs to provide 
> module constructors and destructors even if they do nothing to 
> avoid ABI changes if such logic is added in the future.
>
> But even those can be solved with individual compiler switches. 
> I think betterC should ideally be only be a shortcut for some 
> set of compiler switches that that could all be enabled 
> individually just as well, as opposed to a monolithic set of 
> compiler and language changes.
>
> As for `@nogc`, I do agree it's benefit-to-weight ratio feels 
> questionable. If we didn't have it, I would be sceptical about 
> adding it to the language. But since it has already been in the 
> language for a long time, it needs stronger justification for 
> removal than rejecting it anew would need, even with editions. 
> Plus, people do occasionally find it useful. Therefore I'm a 
> bit sceptical about but not strongly against removing it.

as far as I know theres only 3 ways to care about betterc; and 
none of which get meaningful support; restructuring it to be "pay 
as you go" will probably not find, much less implement, these 
theatrical alt better compiler switches.