On Mon, 12 Sep 2011 11:23:36 -0400, Timon Gehr <timon.g...@gmx.ch> wrote:
On 09/12/2011 05:16 PM, Steven Schveighoffer wrote:
On Mon, 12 Sep 2011 11:02:20 -0400, Timon Gehr <timon.g...@gmx.ch>
wrote:
On 09/12/2011 04:34 PM, Steven Schveighoffer wrote:
On Mon, 12 Sep 2011 10:24:52 -0400, Timon Gehr <timon.g...@gmx.ch>
wrote:
On 09/12/2011 04:17 PM, Steven Schveighoffer wrote:
On Mon, 12 Sep 2011 10:10:35 -0400, Simen Kjaeraas
<simen.kja...@gmail.com> wrote:
On Mon, 12 Sep 2011 00:11:11 +0200, Timon Gehr <timon.g...@gmx.ch>
wrote:
I think the fact that "in" for AAs returns a pointer is a mistake
and
ugly in the first place and any generic code that relies on any
container to return a raw internal pointer is flawed by itself
imho.
If D had a Nullable struct, that would likely be a much better
return
type for 'in'. The thing is, we do have a nullable!T type: T*.
This is simply a case of having a wrench and needing a hammer.
No, the advantage of using a pointer is, you can change the value
without incurring another lookup. A nullable struct does not have
that
advantage.
A decent compiler has that advantage without requiring programmers to
abuse the 'in' operator.
I think the correct return type for that should be a cursor (i.e. a
single-element range which can be used to refer to that element at a
later time). This allows even more functionality, such as removing
the
element, or referring to both the key and value.
The correct return type for 'in' is bool. But the functionality you
propose could be quite useful indeed.
I agree the term 'in' doesn't accurately describe the function I
propose. But then again, AA doesn't provide any other means to avoid
double-lookup.
The compiler could do it, because most cases of double-lookup are
recognized trivially.
I think having a different member function to do the same
thing, and re-purposing 'in' to just return bool would be fine. This
should be entirely possible, since AA's are now at least extendable by
the library.
-Steve
+1. That would be great, because it would eliminate a case of operator
overloading abuse sitting right in the language's core. Also, it would
open up opportunities to reuse the operator for other built-in types.
if(a in [1,5,7,11]){}
is so much better and DRYer than
if(a==1 || a==5 || a==7 || a==11) {}
That still would need special treatment, because in should be fast
(O(lgn) or better), and in on any array is O(n).
O(n) is just fine, because that is the fastest way of searching an
arbitrary array.
No it's not fine. Even if you think it is, you will never get this past
Andrei (or me).
a in b should be fast, it's already associated with efficiency.
I'd say the array had to be a literal, or guaranteed sorted to support
in. I'm not sure that's a great thing.
But in order to do all this, we have to consider that a *lot* of code
relies on a in AA returning a pointer.
What code? I think many people don't notice that it returns a pointer,
because they expect it to return bool.
I use it whenever I use AA's to avoid double lookup. Look in any code
that uses AA's and cares about efficiency:
if(auto v = a in b)
{
*v = newval;
}
else
{
b[a] = newval;
}
I almost think it's too late to make that kind of change (have a in AA
return bool instead of a pointer).
One more point: it's technically not abuse, since a in AA does evaluate
to a bool value meaning "a is in the AA". It's overloading :)
-Steve
auto foo(){
auto x=a in aa;
return x;
}
if(foo())
works just fine ;)
-Steve
