Explicit pack expansion and the Expansion Operator
user1234
user1234 at 12.de
Wed Aug 7 15:56:26 UTC 2024
On Wednesday, 7 August 2024 at 09:57:22 UTC, Quirin Schroll wrote:
> In D, unlike C++, compile-time sequences (a.k.a. packs, tuples,
> alias sequences, and many more) auto-expand. This is usually
> desirable, but sometimes, it requires programmers to write
> auxiliary constructs to get C++-like pattern expansion.
>
> For example, if `pack` is a parameter pack, in D, `f(pack)`
> calls `f` with the pack’s components as parameters. In C++,
> `f(pack)` is, generally speaking, invalid, but requires either
> `f(pack...)` to expand the pack as parameters for `f` or
> `f(pack)...` to create as many invocations of `f` as there are
> pack members, each invocation with 1 argument each. And if `fs`
> is a pack as well, `fs(pack)...` creates lockstepped
> invocations: `fs[0](pack[0])` … `fs[$-1](pack[$-1])`, and the
> packs involved must be of equal length.
>
> Essentially, the `...` postfix operator expands packs in
> lockstep (and repeats non-packs) into a compile-time sequence.
>
> While C++ requires packs to be expanded (except for some
> constructs that handle packs specifically, such as
> `sizeof...`), D never did that. The semantics with `...` are
> simply that if a declaration or statement is complete and
> unexpanded packs remain, those are expanded at the innermost
> possible place.
>
> [...]
About the syntax I think that using the system of type properties
(to be perfectly clear I speak about things like `.stringof`)
would be more judicious than a new operator. Properties dont
require parser modifications. So `.expand`.
More information about the dip.ideas
mailing list