Permalink
Reply
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.
Also add the Expansion Operator opExpand. When a sub-expression e (possibly a type) is part of a pattern that is to be expanded and it defines opExpand, the sub-expression is considered a pack and its expansion is considered to be e.opExpand. In the expansion, it is not necessarily indexed, i.e. opExpand may be a sequence, in which case it is indexed, but it may also be a value, in which case it is repeated. In both cases, though, opExpand keeps expansion from considering sub-expressions. If opExpand is a template, it is passed the length of the expansion as a size_t value argument.
