Read the draft here: https://github.com/Bolpat/DIPs/blob/EnumParameters/DIPs/1NNN-QFS.md

Feedback is welcome.

On Friday, 23 September 2022 at 15:41:21 UTC, Quirin Schroll wrote:

I use enum a lot in my code base, and i think the name of that keyword for that usecase is very wrong, it conveys the wrong intention

enum is supposed to be an enumeration, not a _ for compile time usecase, in fact, comptime is a better name, so i personally would love if it was changed to that, if that's possible

On Friday, 23 September 2022 at 16:17:01 UTC, ryuukk_ wrote:

If you thought about enum c = val;, then we simply disagree about the intention.
If you thought about enum { ... } or enum Name { ... }, then you’re right, but isn’t the enum keyword used quite (if not even more) frequently like this?

enum constant = value;
enum empty = false; // infinite ranges use this

Semantically, enum c = val; is not exactly sugar for enum { c = val }, because enum c(T) = val!T; works, but no equivalent (not even with explicit template) exists for enum {}. They are quite obviously different conceptually. Single enum is exactly what comptime would express: A compile-time only value, or (as I call it in my mind) a named literal (to better understand why an enum with slice type always allocates).

It probably must be an existing keyword. comptime would be possible as a contextual keyword, something Walter opposes. static is the only other candidate. I’ve looked through the whole list of keywords.

On Friday, 23 September 2022 at 15:41:21 UTC, Quirin Schroll wrote:

Some thoughts.

• Does this need __traits(isEnum) (like __traits(isRef)) for working with auto enum parameters?

• Sometimes library authors prefer to have a parameter passed at runtime even when it could be passed at compile time, to avoid template bloat. So for use cases like format and regex, this proposal is not a clear win.

• A significant chunk of the proposed use-cases could also be addressed by adding opStaticIndex. Probably worth mentioning in the "Alternatives" section.

• Incompatibility with other parameter storage classes is a design smell. Ideally, we would like our language features to be orthogonal and work together with each other.

• Similarity to ref is also a design smell. ref is badly designed, and things like auto ref and core.lifetime.forward exist entirely to work around its deficiencies. We should avoid making the same mistake twice.

Overall, my impression is slightly negative. I can see situations where this would be useful, but I'm not convinced it's useful enough to justify the language-complexity and maintenance costs.

On Friday, 23 September 2022 at 15:41:21 UTC, Quirin Schroll wrote:

Regarding Prior Art, this reminds me a lot of C++'s auto function parameters that make the function a template function without the need of the syntax overhead that comes with C++.
It also reminds me of SPIR-V specialisation constants, which serve a different purpose of late binding values for the optimiser.

Those are two incompatible meanings, and it is not entirely clear which one the DIP wants to be. I think the best option would be to have a static opSlice be something else and have enum parameters be values that must resolve at compile time.

This DIP makes no mention of what one can do with an enum parameter. In particular it would be very useful to be able to use CTFE with it, and do static assertions (e.g. check signatures of format strings). and (not that I'm sure there is any easy way to do it) being able to differentiate (and let the compiler know, probably more of a problem for DMD) if the intention is to reduce template bloat (in the case of format) or use the value as a specialisation constant.

This is not the case, for C++ interop reasons (among others) const ref can bind rvalues.

On Friday, 23 September 2022 at 15:41:21 UTC, Quirin Schroll wrote:

I'm a bit torn about static vs enum. I partly agree with prior speakers about enum getting too many meanings, but on the other hand, it's not really a problem imo.

Would it otherwise be called static parameters? Otherwise const of course, but that's already a used attribute.

I think the rationale behind it is solid and would simplify things in the long run (less to think about = better).

On Friday, 23 September 2022 at 15:41:21 UTC, Quirin Schroll wrote:

If it were up to me I'd approve this right now, we need something like comptime.

The exact keyword is not important, enum is okay, static is okay, comptime is okay, whatever.

On Friday, 23 September 2022 at 15:41:21 UTC, Quirin Schroll wrote:

Stop, little pot! We can only eat so much attribute porridge.