I dun a DIP, possibly the best DIP ever

Joseph Rushton Wakeling joseph.wakeling at webdrake.net
Sat Apr 25 11:17:46 UTC 2020


On Saturday, 25 April 2020 at 10:27:38 UTC, Stefan Koch wrote:
> version(dotdotdot)
> {
>     mixin("enum x = (big_seq + 3)....length;");
> }

I have to say I don't find this notation intuitive for meaning.  
`big_seq + 3` would imply that we're adding 3 to `big_seq` 
itself.  But without the surrounding ()... `big_seq + 3` is not a 
valid expression.

This is a case where the pythonic-style `x + 3 for x in big_seq` 
is, while more verbose, probably also a lot clearer.  It makes 
the difference between sequence and element much easier to see.

Compare with say `(big_seq_1 + big_seq_2)...`.  As we discussed 
off the message board, assuming the sequences are of the same 
length, this would result in the elementwise sum.  In other words 
it's about the same as:

     x1 + x2 for (x1, x2) in zip(big_seq_1, big_seq_2)

... but where the latter notation (though verbose) is pretty 
clear in what it means, the former is ambiguous because we have 
to know that `big_seq_1` and `big_seq_2` are both sequences.  In 
this case I used a clear naming scheme, but if in general I see:

     (a + b)...

then I have to know what both `a` and `b` are in order to 
understand clearly what will happen here.

If on the other hand I see:

     a + x for x in b

or

     x + b for x in a

or

     x1 + x2 for (x1, x2) in zip(a, b)

these are all much clearer in intent.

There are obviously other ways in which the `...` operator _is_ 
intuitive and maps well to some existing uses of similar 
notation.  But it would be nice if we could reduce ambiguity of 
intent.


More information about the Digitalmars-d mailing list