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

[Steven Schveighoffer]

On Mon, 12 Sep 2011 11:02:20 -0400, Timon Gehr <timon.gehr at 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.gehr at 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.kjaras at gmail.com> wrote:
>>>>
>>>>> On Mon, 12 Sep 2011 00:11:11 +0200, Timon Gehr <timon.gehr at 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).

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.

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