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

[Timon Gehr]

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#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.

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'.