On Saturday, 28 December 2013 at 19:11:14 UTC, Ola Fosheim
Grøstad wrote:
But the disadvantages are serious, most notably generic code
that uses `in` and assumes it has some complexity guarantee
would experience a blow-up in complexity when an array is
passed.
Ok, I agree with this for simple operators like +, -, * etc.
Whether 'in' is a simple operator probably depends on what you
are used to from other languages.
That's fair enough. I think the safe choice is to wait and see
how it unfolds in libraries to come.
Further, adding syntax sugar to such an operation sends the
wrong signal and is thus asking for trouble during code
maintenance - initially the array might have been small and
use of `in` judicious, but later down the line the array grows
while the use of `in` is preserved because it *looks* low-cost
Depends on where you come from. I think it is quite common in
Python code to test 'in' for short immutable (literal) arrays,
e.g. "if action in ['say','talk','shout']:"
I think it is reasonable to accept that, because the code
becomes much easier to read if you do lots of text processing.
So it depends on what kind of programs you tend to write. It
has no place in a 3D engine, but is useful in text based
adventure games.
For array literals it's not such a bad idea, and was recently
topical in the assessment of `std.algorithm.among`[1]. However,
as elaborated upon in the linked PR, I think the library solution
is superior for D.
[1] https://github.com/D-Programming-Language/phobos/pull/1787
