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.
If querying a collection for the presence of a key makes sense (and it
does to me) then the operator should work across as many collections as
possible, regardless of the running time.
(The presence of optimized variations is a bonus. Not a requirement.)
=Austin
