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