DIPs
DIPs copied to clipboard
Enum Parameters
@Bolpat Thanks for submitting this, but next time please wait until your first draft is complete before submitting the PR. I'd rather keep in-development DIPs out of the queue. Thanks!
@dukc, thank you for reading.
However, I'm less convinced about the
@nodbi
attribute. It solves a problem that can be mostly solved by simply assigning anenum
parameter to a local variable in the [caller]. I do get the attribute has some advantages over that, butenum
arguments are already an advanced language feature that is at the limits of what most people can reasonably comprehend. Having an attribute that adds more rules on top of that probably isn't worth it.
I thought that as well. I put it in because it can easily be removed later and one of the first reactions I got when I put the idea on the forum was: “But what about (template) bloat?” Had I found a workaround to get the benefits it provides, it’d never seen the light of day. I’ve marked it optional for now and I’m currently considering alternative syntax like in enum
as a replacement for @nodbi enum
. My general feeling is that people dislike new attributes far more than combining existing ones with new semantics.
Another rationale for talking about @nodbi
is that people might ask for it. The sections dedicated to it also serve to expose how complicated and subtle the thing they’re having in mind actually is; e.g. the rule “a @nodbi
parameter may only be used in constraints and static assert” won’t do. (If someone finds a simpler rule, I’ll appreciate.)
I'm all for this idea, sans the @nodbi
mechanism (which seems orthogonal and can be added later, also the name needs attention). Technically, also the optimizations can be added later, but do help describe how to avoid template bloat.
FWIW, a similar discussion on the forums brought this idea to the forefront:
https://forum.dlang.org/post/[email protected] https://forum.dlang.org/post/[email protected]
So glad to see this all fleshed out and ready to go!