On Friday, 23 September 2022 at 16:44:05 UTC, Quirin Schroll wrote:

Nevermind. I just found out that attributes for function parameters are a thing as of late. As with @safe, @nogc and @property, @comptime could be another compiler-recognized attribute.

As a member function attribute, @comptime intuitively looks more like it means that the function can only be used for CTFE and never at run-time (cf. consteval in C++; something like this was suggested for D before).

On Friday, 23 September 2022 at 17:54:49 UTC, Paul Backus wrote:

Good catch, __traits(isEnum) does not exist currently. But it makes sense to add it, not only for this proposal, but generally. I’ll add that.

Is that the case? Of course, you get one additional template instantiation for regex because it normally is not a template at all. format is already a template; with a template argument format, you ideally only get a different instantiation. A high number of template instances is usually only a problem if the templates are recursive. If it happens to be a problem, one can always put the format or regex in a local variable and use that. This workaround is harder if you also want the value to be an rvalue; you’ll then need to define a function that returns the value and takes a run-time value as a parameter (that it won’t actually use) so that CTFE is out of the picture.
This is a niche case; I guess it’s okay for this to be a little work.

I wrote a draft for static indexing. There, I mentioned that something like this, i.e. a feature to pass parameters at compile-time were added, it would supersede the proposal. I figured that it was actually easier to specify and explain compile-time parameter passing than static indexing.

Static indexing with a completely separate set of operators almost doubles the jungle of indexing operators and is very specific.

Maybe you got this wrong. It is not that by virtue of enum any thinkable parameter storage class would be incompatible. It is just that all of the existing ones are.

enum is a stronger form of in and thus is in the same group with in, out, and ref, which specify parameter passing. Two of them together would have a very specific meaning and not simply the rules for both because that would be contradictory.

Let’s go through the list:

• auto can only be used in conjunction with ref to form auto ref. Alone, it is invalid.
• TypeCtor are allowed. It says so in the DIP.
• final as far as I know is only there to generate a specific error; it is never valid.
• in (see below)²
• lazy makes no sense; the value is already produced at compile-time.
• out is incompatible with enum because enum values are never lvalues and cannot be written to.
• ref is incompatible with enum because enum values are never lvalues.
• return is really only something for run-time values.¹
• scope is really only something for run-time values.¹

¹ To be honest, I don’t know how scope and by extension return would apply to compile-time constants. If I’m not mistaken, life-time of those objects is infinite.

² The in storage class means const scope and maybe ref. enum is incompatible with ref, scope does not apply.

I see how auto ref has flaws because the value category is not preserved, i.e. the parameter is an lvalue regardless whether it was initialized by an rvalue or lvalue. This is where the analogy parts. An auto enum parameter initialized by a compile-time constant is a compile-time constant and an auto enum parameter initialized by a run-time value is a run-time value. Nothing has to be done to forward.

The analogy is limited to the way overloading and inference on the category (value category for ref and compile-time category for enum) works.

That’s what I’m trying to find out.

On Saturday, 24 September 2022 at 07:51:32 UTC, Imperatorn wrote:

Its not really adding a new meaning, enum already (somtimes) means "do this at compile time", that's really the problem, that usage of enum has literally nothing to do with enumeration. It's like we've run out of English words so we have to use "count" any time we want to say "now".

Using enum to mean "compile time" or "manifest constant" should be depreciated in favour of a keyword that actually at least vaguely relates to those meanings.

On Saturday, 24 September 2022 at 00:12:35 UTC, Timon Gehr wrote:

Thanks.

Happens to the best. 😅

Yes, I have to make this clear. CTFE must be attempted when binding to auto enum. It only becomes to non-enum if enum (without auto) would not be able to bind the argument. (Similarly, auto ref is required to bind as ref even if it could bind via copy.)

I don’t really know what you mean exactly. Maybe this section:

By the way, I’ve figured the explanation in the DIP is wrong. enum values are not immutable or effectively immutable. It appears that the semantics of enum currently make the value a literal for the first and second level of indirection. The other parts are mutable unless qualified, and do not count as mutable global state as far as pure is concerned. Issue 23375

I realized when answering to Paul Backus about the incompatibility with storage classes, in particular scope. I created some examples with indirections and found bugs.

Sorry in advance for the long answer.

On Saturday, 24 September 2022 at 01:25:17 UTC, Nicholas Wilson wrote:

The key difference here is that C++ template syntax is verbose and auto is a syntax sugar.
I thought about having functions with enum parameters be templates implicitly. I decided against that. For one, it could be allowed later if deemed useful, for second, making a function a function template in D requires adding () between the name and the parameter list. I.e.

void f(enum int i) { } // error, f is not a template
void g()(enum int i) { } // this is how it’s done

I know nothing about SPIR-V. If you don’t mind, you can explain it to me or send me a link to a description.

Do you mean that that they must resolve at compile-time and then be run-time values? That would throw away valuable information with virtually no gain.

It does, three examples are provided: format, regex, static indexing. You can do with them whatever you can do with template value parameters.

That is exactly the specified semantics. I thought about defining the feature in terms or rewrites. Those would make the proposal more understandable, but also constrain the implementation. Also, it would define things to be a certain way that could be depended upon.

Potential rewrite implementation examples for

void f(T)(enum T x, T y) { /+impl+/ }

(A) Append the enum parameters to the template argument list (cf. C++ auto parameters).

void f(T, T x)(T y) { /+impl+/ }
// which in turn is actually
template f(T, T x)
{
    void f(T y) { /+impl+/ }
}

f(10, 20) // equivalently, 10.f(20)
// is actually
f!(int, 10)(20)

(B) Nested template

template f(T)
{
    template f(T x)
    {
        void f(T y) { /+impl+/ }
    }
}

f(10, 20)
// is actually
(f!int)!10(20) // note: syntactically invalid,
// i.e. in code, it must be:
Instantiate!(f!int, 10)(20)

I guess both have their upsides and downsides. I did not investigate this further. Again, it need not be a rewrite at all, and I don’t think it will be, unless someone has a great idea that has no weird semantics.

I tried on run.dlang.io/nightly, this statement is wrong; const ref parameters cannot bind rvalues.
You can, however, use in instead of const ref. With -preview=in, in on parameters of an extern(C++) function means what const& means in C++.
Example:

extern(C++) void f(const ref int x) { }
extern(C++) void g(in int x) { }
void main()
{
    f(1); // error
    g(1); // good
}

DIP 1016 wanted ref to be able to bind rvalues. It was rejected.

On Saturday, 24 September 2022 at 07:51:32 UTC, Imperatorn wrote:

One biggie against using static is that on member functions it would have to go to the back (where it is currently invalid) with a totally different meaning than in front (although it would make the function a static).

Non-member:

void f()(static int ctValue) { } // this is fine

Member:

struct S
{
    void f()() static { } // different from:
    static void g()() { }

    void p()() enum { } // same as
    enum void q()() { }
}

This would be no problem if D did not allow putting some stuff before and after the function declaration with the same meaning. I really dislike void f()() static { }.

Currently, enum is valid for member functions like q, but does nothing. That would change, but I’d bet that almost no one has this in their code base anyway, so breakage would be minimal.

On Monday, 26 September 2022 at 09:18:54 UTC, claptrap wrote:

The value of that would be close to zero. At least in Phobos, enum is more often used to define a single value than an enumeration type.

With a new keyword, we’d need to deprecate enum or have both, also we’d have make sure the new keyword is dissimilar to identifiers currently used not to break code. On parameters, a compiler-recognized UDA, say @comptime, would be an alternative, but that cannot be trivially used instead of enum without special-casing it in the grammar. Inconsistency is worse than bad naming. Also, I don’t think that enum is actually a bad name. It has a specific meaning in D, but apart from that, it’s not that bad.

[Half Joking] Another option would be no keyword at all, but some kind of other token. But I guess no one prefers f()(^int x) or similar over f(enum int x).

On Monday, 26 September 2022 at 11:23:58 UTC, Quirin Schroll wrote:

True, and we're used to enum behaving like that, so I guess it's preferrable

On Monday, 26 September 2022 at 09:18:54 UTC, claptrap wrote:

Hmm, yes, this is the other sane option. To actually introduce a new keyword to differentiate

On Monday, 26 September 2022 at 11:55:00 UTC, Imperatorn wrote:

Maybe a keyword like fixed, invariant could be used. I don't know how immutable would work since it's already used.