On Thu, 07 Oct 2010 13:28:51 -0400, Austin Hastings <ah0801...@yahoo.com>
wrote:
On 10/7/2010 10:52 AM, Andrei Alexandrescu wrote:
On 10/7/10 6:54 CDT, atommixz wrote:
It would be nice if it were possible to use the "in" expression
wherever
possible. Now it is only implemented for associative. arrays. (Weird).
Examples of how this could be used:
- Find string in string
- Search for a character in a string
- Search for an item in the array, array of characters, array of
strings,
tuples, enum, structure
- what else?
In Python done something like this.
Here it would be useful to me
http://code.google.com/p/atommixz/source/browse/analyze-x86/analyze-x86.py
http://code.google.com/p/atommixz/source/browse/analyze-x86/analyzex86.d
I'm a bit leary of adopting this feature (it has been discussed). To me
"in" implies a fast operation and substring searching isn't quite it.
One thing that could be done is to allow "in" with literal arrays to
their right:
if (x in ["abcde", "asd"]) { ... }
The size of the operand is constant, known, and visible.
Andrei
This is a non-argument. "In" is an operator. "*" is an operator.
Everyone "knew" that multiplying longs was slower than multiplying ints.
Everyone "knew" that multiplying floating point was slower than
multiplying integers. But * was still defined for floating point types
because it made sense.
No, this is not just a difference in runtime, this is a difference in
complexity. The complexity of in on an associative array is O(1), the
complexity of in on an array is O(n). This is a huge difference from
comparing multiplying floats and ints.
in's complexity should be O(lg(n)) or better.
I also disagree with Andrei that in could work on arrays in certain
cases. It has no business being called on an array, we already have find.
-Steve
