Feedback Thread: DIP 1037--Add Unary Operator ...--Community Review Round 1

[Andrei Alexandrescu]

Incidentally I'm working on a book chapter on C++ variadics and just 
read through the standard 
(https://github.com/cplusplus/draft/blob/master/papers/n4140.pdf, search 
for "variadic" and "pack"). It provides a good baseline for evaluating 
this proposal.

Overall: the proposal is imprecise and needs a lot more fleshing out in 
order to provide an actual specification for implementation.

Abstract: should not be an executive review consisting of only one 
confusing sentence ("..." is not an expression, it's punctuation or 
operator). Abstract should clarify how explicit tuple expansion compares 
with the existing implicit expansion.

* "...the mechanisms to implement them in D are awkward..." they are the 
standard functional approach. The DIP should at best refrain from making 
subjective evaluation. The high compile-time cost is good rationale.

* The proposal does not mention things like Reverse, Sort etc., which 
would need non-forward iteration to work efficiently and are not helped 
by the proposal.

* "often reaching quadratic complexity for relatively simple operations" 
-> a couple of (references to) examples would be great

* "...expression to perform explicit tuple expansions at the expression 
level, which can express..." good candidate for rephrasing

* "a unary ... syntax" -> "s a unary ... postfix operator"

* "(Tup*10)...  -->  ( Tup[0]*10, Tup[1]*10, Tup[2]*10 )" -> the example 
does not clarify how one expression expands into multiple expressions; 
this is not something that an operator does. The parens don't help - are 
they required, provided for illustration...? The meaning of the 
expansion (e.g. array initialization vs. function call etc) is 
determined by the context of the expansion. That's why the C++ proposal 
and standard focus most of the description on expansion loci.

* "C++11 implemented template parameter pack expansion with similar 
semantics, and it has been a great success in the language. Coupled with 
D's superior metaprogramming feature set, D users can gain even greater 
value from this novel feature." -> specious argument, even if we allow 
for the "great success" in C++. (Most uses of "..." in C++ are sheer 
black magic and have required simplifications in C++17. NOT a success 
story.) The main problem is different though. C++ parameter packs don't 
enjoy /any/ other operation aside from expansion and "...". To add that 
to the many existing operators for tuples that D has and claim it'll 
just work great because it did in C++ does not stand to reason.

* Major bug: the "Rationale" discusses only expression, whereas 
staticMap does not use expressions. It just processes tuples, which may 
contain types. Types cannot appear in expressions. C++ goes to great 
lengths to distinguish between template parameter packs (which may be 
one of type parameter pack, value parameter pack, and template template 
parameter pack) and function parameter packs (which may only be 
parameter declarations). By the Rationale nothing except expressions 
will be accessible to D's proposed "...". That means no staticMap for 
non-valies (e.g. staticMap!(Unqual, types)), which probably wasn't the 
intent of the DIP.

* "The implementation will explore expr" -> there's no formal definition 
of "explore". The C++ spec mentions "the largest expression to the left 
of the ...". Probably that would work here, too.

* "A second form shall exist which may implement a static reduce 
operation with the syntax expr [BinOp] ..." What happens if the tuple is 
empty? C++17 allows ... only in between operators, e.g.:

return false || ... || args == value;

thus allowing the author to choose the limit value.

* The "Compliation Performance" needs to discuss how the operator 
handles backward iteration.