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

[Jonathan M Davis]

On Monday, September 12, 2011 01:04:39 Timon Gehr wrote:
> On 09/12/2011 12:21 AM, Jonathan M Davis wrote:
> > 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#Bina
> >>>>>> ry
> >>>>> 
> >>>>> // 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.
> 
> AAs are built-in. The optimization you describe is quite easily carried
> out by the compiler. And I am quite sure that in the long run, it will
> bite us.
> 
> Sure. D is a systems language and you should probably be able to have
> the (unsafe) functionality. But 'in' is a predicate as in x ∈ M . It is
> really supposed to return a bool. I think Andrei even successfully
> avoids to mention the fact that it returns a pointer in TDPL.
> 
> 
> BTW: Why does the current AA implementation rely on the GC if not for
> avoiding dangling pointers escaped by in expressions? I think if it is
> the only reason, efficiency concerns cannot be a rationale for the
> 'feature'.

It is no more dangerous than keeping an iterator or range around after its 
been invalidated. In fact, it's _exactly_ the same thing. And there's no way 
that you're going to get rid of that issue in an efficient manner. That's why 
std.container has the stable* functions. Pointers are allowed in SafeD and are 
perfectly safe. It's stuff like pointer arithmetic which is unsafe and 
disallowed in SafeD.

Yes, there are issues if you keep the pointer around after the container has 
been altered, but ranges have exactly the same issue. It's a known and 
accepted problem. The solution is to just not keep the pointer around. If a 
programmer keeps such a pointer aronud (or keeps a range around after altering 
a container with a non-stable* function), then they're risking buggy code. 
That doesn't mean that the feature is a bad idea.

- Jonathan M Davis