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

[Timon Gehr]

On 09/12/2011 05:16 PM, Steven Schveighoffer wrote:
> 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).

O(n) is just fine, because that is the fastest way of searching an 
arbitrary array.

>
> 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 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;
}