Enum Parameters

[Bolpat]

No description provided.

[mdparker]

@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]

I find this DIP interesting. It has fairly high potential for design problems that are hard to foresee, since many expressions that are currently always runtime can become compile-time. But it also enables so much new patterns that I think this is worth exploring further.

However, I'm less convinced about the @nodbi attribute. It solves a problem that can be mostly solvedl by simply assigning an enum parameter to a local variable in the function. I do get the attribute has some advantages over that, but enum 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.

[Bolpat]

@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 an enum parameter to a local variable in the [caller]. I do get the attribute has some advantages over that, but enum 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.)

[schveiguy]

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/unseru$167e$1@digitalmars.com
https://forum.dlang.org/post/ojotybtiosjikmmcxemw@forum.dlang.org

So glad to see this all fleshed out and ready to go!