Bill Baxter wrote:
> I keep wanting to say
>   if (val in somearray) {
>   }

Wait! That's just it!

It's "KEY in CONTAINER" and the KEY of a regular array is the index, not the value. So dare I suggest the following instead?

if (index in somearray) {
}

This "in" would be:
(cast(size_t)index < somearray.length?&somearray[index]:null)

Totally analogous to the associative array. And it also solves the "Length comparison" issue.

L.

Lionello Lunesu wrote:
> Bill Baxter wrote:
> 
>> I keep wanting to say
>>   if (val in somearray) {
>>   }
> 
> 
> Wait! That's just it!
> 
> It's "KEY in CONTAINER" and the KEY of a regular array is the index, not the value. So dare I suggest the following instead?
> 
> if (index in somearray) {
> }
> 
> This "in" would be:
> (cast(size_t)index < somearray.length?&somearray[index]:null)
> 
> Totally analogous to the associative array. And it also solves the "Length comparison" issue.
> 
> L.

hmmm, seems unintuitive to me.  I tend to think of the "in" operator acting on a set and a potential member of the set.  I also tend to think of an array as a set of somethings.  Now when I make an int[] and say something like if( 14 in somethings ) I'd expect it to look through the set of somethings and see if the number 14 is in there.  I wouldn't expect it to look through the set of integers that are less than somethings.length to see if 14 is in that.

Now I'm wondering, why is it a good idea to have "in" mean what it does for aa's?  It seems to hold back a lot of other stuff, and not provide much.  It would be nice to be able to write foreach(value in array) instead of using the strange semicolon syntax - and this is very common.  I doubt the current usage of "in" is anywhere near as common as that, or even as common as something like if(ipAddy in ipAddresses).  Thus it would be more appropriate to, in those few cases of aa "in" usage, instead write aa.hasKey(key) instead of (key in aa).  Changing that would also allow you to write (value in aa).

Notice that associative arrays have a .keys property.  Perhaps then, we could simply define the current usage of "in" - (key in aa) - to be shorthand for (key in aa.keys).  With that "in" has a more intuitive meaning, IMO.

Lionello Lunesu wrote:
> Bill Baxter wrote:
>> I keep wanting to say
>>   if (val in somearray) {
>>   }
> 
> Wait! That's just it!
> 
> It's "KEY in CONTAINER" and the KEY of a regular array is the index, not the value. So dare I suggest the following instead?
> 
> if (index in somearray) {
> }
> 
> This "in" would be:
> (cast(size_t)index < somearray.length?&somearray[index]:null)
> 
> Totally analogous to the associative array. And it also solves the "Length comparison" issue.
> 
> L.

Now this I actually like... Can already think of places I could use it, such as in Bovis during symbol/id lookups.  Its a nice idea.  (Might just add it to Cashew in the meantime.)

-- Chris Nicholson-Sauls

Chris Nicholson-Sauls wrote:
> Lionello Lunesu wrote:
> 
>> Bill Baxter wrote:
>>
>>> I keep wanting to say
>>>   if (val in somearray) {
>>>   }
>>
>>
>> Wait! That's just it!
>>
>> It's "KEY in CONTAINER" and the KEY of a regular array is the index, not the value. So dare I suggest the following instead?
>>
>> if (index in somearray) {
>> }
>>
>> This "in" would be:
>> (cast(size_t)index < somearray.length?&somearray[index]:null)
>>
>> Totally analogous to the associative array. And it also solves the "Length comparison" issue.
>>
>> L.
> 
> 
> Now this I actually like... Can already think of places I could use it, such as in Bovis during symbol/id lookups.  Its a nice idea.  (Might just add it to Cashew in the meantime.)
> 
> -- Chris Nicholson-Sauls

Ugh.  I've created a monster.

That would make sense in Lua where there is only one data structure (table), which can be indexed with numbers or non-numbers equally well, but in D, it just doesn't seem right to say 2 is 'in' ["spam","eggs","spam"].  I certainly don't see any 2 in there.  The operation you want seems more like a get():

   T* get(T[] arr, size_t index) {
      return (index < arr.length ? &arr[index] : null)
   }

   if (somearray.get(10)) {
   }

The dict type in Python uses something like that for safe indexing, otherwise you use [] if throwing an exception is ok.

--bb

Alexander Panek wrote:
> Lionello Lunesu wrote:
>> Alexander Panek wrote:
>>> Lionello Lunesu wrote:
>>>> switch(val) {
>>>>   case "off","disable","no":
>>>>      // code here
>>>>   default:
>>>>      break;
>>>> }
>>> May I ask in what way this is different from:
>>>
>>> switch ( val ) {
>>>     case "off":
>>>     case "disable":
>>>     case "no":
>>>         // code here
>>>         break;
>>> }
>>
>> case x,y: is the same as case x: case y:
>> Apart from that, if you don't provide a 'default' statement, D inserts one with assert(0), meaning that your code would trip if val were anything other than those 3 mentioned cases.
>>
>> L.
> 
> Yea..I've seen that I forgot the default: break; after replying.. :P

And you're very likely to forget it when writing code ..

Hasan Aljudy wrote:
> 
> 
> Alexander Panek wrote:
>> Lionello Lunesu wrote:
>>> Alexander Panek wrote:
>>>> Lionello Lunesu wrote:
>>>>> switch(val) {
>>>>>   case "off","disable","no":
>>>>>      // code here
>>>>>   default:
>>>>>      break;
>>>>> }
>>>> May I ask in what way this is different from:
>>>>
>>>> switch ( val ) {
>>>>     case "off":
>>>>     case "disable":
>>>>     case "no":
>>>>         // code here
>>>>         break;
>>>> }
>>>
>>> case x,y: is the same as case x: case y:
>>> Apart from that, if you don't provide a 'default' statement, D inserts one with assert(0), meaning that your code would trip if val were anything other than those 3 mentioned cases.
>>>
>>> L.
>>
>> Yea..I've seen that I forgot the default: break; after replying.. :P
> 
> And you're very likely to forget it when writing code ..

I usually don't forget it..actually. But that's just me. ;)
(In this case lack of time prevented any re-reading :O )

Tuples, For The Win.

This is a prime example of why we can overload operators in D, and how templates further enhance that capability.  There's little need to add language features when the language supports so many possible constructs already.

Jarrett Billingsley wrote:
>
> struct _Tuple(T...)
> {
>  bool opIn_r(U)(U value)
>  {
>   foreach(val; T)
>   {
>    static if(is(typeof(val) : U))
>    {
>     if(val == value)
>      return true;
>    }
>   }
> 
>   return false;
>  }
> }
> 
> template Tuple(T...)
> {
>  const _Tuple!(T) Tuple;
> }
> 
> void main()
> {
>  if(4 in Tuple!("hi", 5.5, 4))
>   writefln("yep");
>  else
>   writefln("nope");
> 
>  if("no" in Tuple!("hi", 5.5, 4))
>   writefln("yep");
>  else
>   writefln("nope");
> }
> 
> 
> Meh.  :) 
> 
> 


-- 
- EricAnderton at yahoo

Bill Baxter wrote:
> I keep wanting to say
>   if (val in somearray) {
>   }
> 
> but 'in' doesn't work for arrays...  Is there any reason why not?
<snip>

You appear to be wanting it to find a given _value_ in an array. Several people have requested this.  The problem is that it would create a confusing inconsistency with associative arrays, in which it is defined to find a given _key_.

Logically, if in does anything on linear arrays, then it should check whether the given index is within the array's bounds.  This isn't just purism - it's also a generic programming concern.

Moreover, if we were to define an operator that finds a given _value_ in a linear array, we ought to have it for AAs too.

Stewart.

On Thu, 07 Dec 2006 22:26:15 +0000, Stewart Gordon wrote:

Is this useful to someone?

// -----------------
template ContainsFrom (T)
{
    // Return 'index' if 'element' found in 'array' otherwise return -1
    int ContainsFrom(T[] pArray, T pElement, int pIndex)
    {
        if (pIndex >= 0)
        {
            while (pIndex < pArray.length)
            {
                if (pElement == pArray[pIndex])
                    return pIndex;
                pIndex++;
            }
        }
        return -1; // Not Found
    }
}

template Contains (T)
{
    int Contains(T[] pArray, T pElement)
    {
        return ContainsFrom(pArray,pElement,0);
    }

}

unittest
{

   int[] X;
   X ~= 3;
   X ~= 2;
   X ~= 6;
   X ~= 8;
   X ~= 1;

   assert(X.Contains(8)  == 3);
   assert(X.Contains(3)  == 0);
   assert(X.Contains(-1) == -1);
   assert(X.Contains(99) == -1);
   assert(X.ContainsFrom(8,4)  == -1);
   assert(X.ContainsFrom(8,2)  == 3);


   char[] Y = "qwerty";

   assert(Y.Contains('a') == -1);
   assert(Y.Contains('q') == 0);
   assert(Y.Contains('t') == 4);
   assert(Y.Contains('z') == -1);

}

// -------------


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
8/12/2006 9:52:26 AM

Stewart Gordon wrote:
> Bill Baxter wrote:
>> I keep wanting to say
>>   if (val in somearray) {
>>   }
>>
>> but 'in' doesn't work for arrays...  Is there any reason why not?
> <snip>
> 
> You appear to be wanting it to find a given _value_ in an array. Several people have requested this.  The problem is that it would create a confusing inconsistency with associative arrays, in which it is defined to find a given _key_.

Confusing to whom?  That's the way it works in Python, and it never seemed the least bit odd or confusing to me, nor dare I say to the vast majority of Python users.

If you want to check for a value in an AA all you would need is
"v in aa.values".  There's no need for a special 'check values' function.

> Logically, if in does anything on linear arrays, then it should check whether the given index is within the array's bounds. This isn't just
> purism - it's also a generic programming concern.

Depends on how you think of an array.  Technically, yes, that's logical if you think of an array as a function that maps natural numbers to values (which is the functional purist's view).  But in terms of usage, for the most part arrays tend to be more like generic containers for (ordered) values, stored adjacent to each other in memory because that's the most efficient for certain applications.

The fact that I access an element by an index is just a side effect of that.  In fact sometimes I don't use indices, I use pointers instead. Should 'x in array' check if the pointer value x is array's memory range?

Arrays, linked lists, sets -- for a lot of purposes they are basically interchangeable.  They're all just containers that hold values.  Which one you choose just depends on what operations on those values need to be fast for your application, and what sort of ordering matters to you.  In my experience it's much more common to start with an array then realize at some point that insertion matters to me more than random access, so I switch to a linked list.  In that case should 'x in container' change from querying if the index is in the container to querying if the value is in the container (which is the only logical thing for 'in' to do on a linked list)?  Seems 'generic programming concerns' in that case would be better served by having 'in' check values.

For practical purposes, arrays, lists, and sets are much more similar to each other than arrays and associative arrays.  So if there is any 'generic programming concern' it should default to making the lists/array/set types be generically interchangeable, not arrays and associative arrays.

And that's all I'm gonna say about it.  There's reasonable arguments both ways and neither argument amounts to a hill of beans if Walter isn't interested.

--bb