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.
