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