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

About prior work, you could take a look at comptime from Zig and static from Nim.

On Tuesday, 27 September 2022 at 00:47:31 UTC, victoroak wrote:

For anyone else interested, the relevant sections are:

• Zig: Comptime
• Nim: static[T]

Thank you.

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

I am really confused about how it differs from what we have now with templates.

Like how is this:

auto opSlice()(enum size_t l, enum size_t u) => slice!(l, u);

An improvement over:

auto opSlice(size_t l, size_t u)() => slice!(l, u);

Maybe I am not entirely grasping this concept or something.

On Tuesday, 27 September 2022 at 11:52:03 UTC, bauss wrote:

auto opSlice()(enum size_t l, enum size_t u) => slice!(l, u);

auto opSlice(size_t l, size_t u)() => slice!(l, u);

The only difference is that at the call site, you can write opSlice(i, j) instead of opSlice!(i, j). It's pure syntax sugar.

On Tuesday, 27 September 2022 at 12:13:53 UTC, Paul Backus wrote:

auto opSlice()(enum size_t l, enum size_t u) => slice!(l, u);

auto opSlice(size_t l, size_t u)() => slice!(l, u);

Yeah that's what I thought.

I'm not for this particular DIP then. I think adding more keywords is going to make the language much more messy.

On Tuesday, 27 September 2022 at 11:52:03 UTC, bauss wrote:

Calling syntax: “The difference between enum parameters and template value parameters is only in calling syntax: f!ct_value(args) versus f(ct_value, args)” And that difference matters for meta-programming and operator rewrites.

auto opSlice()(enum size_t l, enum size_t u) => slice!(l, u);

auto opSlice(size_t l, size_t u)() => slice!(l, u);

TL;DR: Because the former one works for an operator rewrite while the latter does not, and changing that in a consistent way is very likely a breaking change. ― end TL;DR

You can call both explicitly, i.e. tup.opSlice!(0, 2) will perfectly compile, but that’s not why we defined opSlice. The syntax tup[l .. u] rewrites to the first one of those that compiles:

1. tup.opIndex(tup.opSlice!0(l, u))
2. tup.opSlice(l, u)

What is not in the list is tup.opSlice!(l, u)() which currently would have to be for it to work, but probably cannot without breaking code.

It’s a bit long, but if you take a look at Operator Overloading § Array Indexing and Slicing Operators Overloading, you’ll notice that the only template parameters involved are supplying opDollar and opSlice (the one that rewrites the l..u pseudo-subexpression when indexing) with the position in the argument list they appeared in.

In 2020, I drafted a DIP for Compile-time Indexing Operators, which is a different feature with a wild range of consequences if thought to its conclusion, among which is spreading the indexable sequence and overload spreading in and of itself. In its Alternative section, § Compile-time Function Parameters, I’ve already outlined the enum parameters DIP and that a large portion of static indexing would be superseded by enum parameters.

Note that the draft is older and when writing something, I rather put it in than leave it out as after review, stuff can always be deleted, but a thought never put down may be gone forever.

On Tuesday, 27 September 2022 at 12:23:18 UTC, bauss wrote:

auto opSlice()(enum size_t l, enum size_t u) => slice!(l, u);

auto opSlice(size_t l, size_t u)() => slice!(l, u);

You probably mean adding more language constructs. enum is already a keyword. Compile-time values are already a thing in D. It would be valuable if you provide examples or some further explanations that demonstrate the mess introduced.

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

So my first thought seeing this was that enum parameters would bind to compile-time constants but don't incur extra codegen for each value passed in, and auto enum, when used once at least, would implicitly generate exactly two copies. But given this, I don't think that's what you're saying:

So the DIP exists purely to introduce a more unified calling syntax?

On Tuesday, 27 September 2022 at 14:39:58 UTC, TheGag96 wrote:

Yes. If you boil it down to a short and vague sentence, you’re right.

It’s another way to get compile-time information into a function that is – notably – syntactically identical to passing run-time information into a function. This is on purpose so the function can potentially react to information passed this way or the other and in the compile-time case, on the information itself, and the user need not care at all.