defining "in" What is the proper way in D2?

[Jonathan M Davis]

On Monday, September 12, 2011 00:11:11 Timon Gehr wrote:
> On 09/11/2011 11:12 PM, Jonathan M Davis wrote:
> > On Sunday, September 11, 2011 14:00:55 Charles Hixson wrote:
> >> On 09/11/2011 01:25 PM, Vladimir Panteleev wrote:
> >>> On Sun, 11 Sep 2011 23:02:37 +0300, Charles Hixson
> >>> 
> >>> <charleshixsn at earthlink.net>  wrote:
> >>>> I can't figure it out from
> >>>> http://www.digitalmars.com/d/2.0/operatoroverloading.html#Binary
> >>> 
> >>> // I assume your data structure looks like this
> >>> class Node(Key, Data)
> >>> {
> >>> Key k;
> >>> Node!(Key, Data) left, right;
> >>> int level;
> >>> // ...
> >>> 
> >>> void opBinary!("in")(Key k)
> >>> {
> >>> if (level == 0) return false;
> >>> if (k<  key) return k in left;
> >>> if (key<  k) return k in right;
> >>> return true;
> >>> }
> >>> }
> >> 
> >> VOID??  I'm going to presume that this should have been bool.
> >> Otherwise, thanks.  That was they syntax I couldn't figure out from
> >> the
> >> docs.
> >> 
> >> And, yeah.  That's what it looks like.  My find code was wrong,
> >> because
> >> it should have referenced the node, so what I need to do is move the
> >> cod
> >> into the node class.  But it was the syntax of defining the opBinary
> >> specialization that was hanging me up.  (For some reason I have a hard
> >> time wrapping my mind around template code.)
> > 
> > The "in" operator normally returns a pointer to the value that you're
> > trying to find (and returns null if it's not there). Making it return
> > bool may work, but it's going to be a problem for generic code.
> 
> -1
> 
> 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.

It's an issue of efficiency. It's more efficient to grab the item once, getting 
null if it's not there, then it is to check if it's there and then grab it. 
Being a systems language, D is _very_ interested in efficiency. Keeping the 
pointer returned from in around for much after the call is likely to be bad 
code (and can certainly lead to problems), but there's nothing unsafe about 
the pointer in and of itself.

> > That's like making
> > opBinary!"*" return a type different than the types being multiplied.
> > It's just not how the operator is supposed to be used and could cause
> > problems.
> short a,b;
> static assert(!is(typeof(a * b) == short));

Those are primitive types, not user-defined types. They are also effectively 
derived types in terms of how they function. There's a big difference between 
returning a derived type and returning a completely different type.

- Jonathan M Davis