`static` on module-level functions

[IchorDev]

On Friday, 7 July 2023 at 13:31:59 UTC, Steven Schveighoffer 
wrote:
>
> D allows no-op attributes in many cases because you can 
> possibly apply attributes to a group via `attribute:` or 
> `attribute { ... }`, and you may not want to fine-tune which 
> things can get the attribute to avoid errors.
>
> Here's a fun one:
>
> ```d
> enum foo() {
>    return "what?";
> }
> ```
>
> What does this mean? `enum` is a storage class, and any storage 
> class applied to a function is going to cause the function to 
> be inferred return type. So effectively, the `enum` does 
> nothing but take the place of `auto`. (`foo` is a function that 
> returns `string`)
>
> However, I can't think of a valid reason to allow `static` on a 
> module-level scope. Applying static to a declaration at 
> module-level should be a no-op. So maybe that's one "use" of 
> static that can be eliminated.
>
> -Steve

Ah yes, that's another beginner's trap—`enum` functions.

We should really make `enum` for functions mean "CTFE-only", or 
something similar. Granted, you can *kinda* do that already with 
lambda enums, as long as you make sure not to call them in 
runtime code. However, enum templates can't be implicitly 
instantiated from eponymous lambda parameters like with function 
templates, and getting errors about "`__lambda7`" instead of 
"`thisFnName`" isn't great either. As it is, it at least makes it 
possible for BetterC code to use compile-time GC for mixin 
generation, I just wish it was a little bit nicer.