On 04/29/2011 07:13 AM, Jacob Carlborg wrote:
On 2011-04-28 21:46, Timon Gehr wrote:
Andrei Alexandrescu wrote:
On 4/28/11 11:00 AM, Alexander wrote:
On 28.04.2011 17:46, Andrej Mitrovic wrote:
It works, but it makes the if statement ugly again. :)
Well, just a bit - still much better than (var == "..." || var =
"...">||
var == "..." ...), don't you think so? ;)
If compiler would support special "in" usage, automatically expanding
values on the right to series of comparisons (like "var in
[1,2,3,4,5]"),>>it
would be really nice, of course :)
That was discussed, too. Walter and I support that although it's a
special case. We didn't get around to talk the purist police into
accepting it.
Andrei
Why is this a special case? The 'in' could be extended operator to
generally work
on arrays (using a simple linear search). The compiler could then
optimize the
given expression the way suggested (actually even to 1<=var&&var<=5).
Why is 'in' not currently defined on arrays? To me it seems like a
left-out that
should be fixed, because it has quite obvious and useful semantics.
Timon
This has been discussed many times before and the general argument
against it is that "in" is available for associative arrays and it tests
for keys. With arrays it would test for values.
The only thing I can compare this with is python's 'in' operator. It's
purpose is different though. In python, 'in' returns a boolean, and the
operator works for any sequence. Associative arrays can return a set of
keys (hashed), or a list (array) of values, and the 'in' operator can be
used on either, but defaults to keys.
Not only have I missed a 'set' data structure, but I have missed the
'in' for arrays as well. It's value is suspect when we consider that
currently the 'in' operator returns a pointer to the value in the
associative array. What would we do for an array? You don't need the
pointer to the value, because you have the value already that you're
looking for. I see the value in returning the pointer in the associative
array, so you don't have to do the look-up again.
My argument is that all sequences and containers should support some
flavor of the "Do I contain this?" question. How many times are we asked
to build a collection bucket, and then asked to retrieve something put
in there? In the case of the OP, he has a static compile-time bucket
that he wants to go poking around in.
If we had a built-in "set" data structure (you know, just the key
portion of the Associative array), we would solve the OP's problem, and
make some of my dreams come true.
