www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - In expression for array

reply kede <nobody gmail.com> writes:
Hi All,

How about adding In expressions for general arrays in addition to assoc arrays:

 if ('i' in eyes)
 ...

as a simple replacement for the more verbose
 foreach(c; eyes)
   if (c == 'i')
     ...

I think its a common enough pattern to warrant inclusion?

Have fun,
kede
Jan 23 2008
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to kede,

 Hi All,
 
 How about adding In expressions for general arrays in addition to
 assoc arrays:
 
 if ('i' in eyes)
 ...
 as a simple replacement for the more verbose
 foreach(c; eyes)
 if (c == 'i')
 ...
 I think its a common enough pattern to warrant inclusion?
 
 Have fun,
 kede

this suggestion comes up about every other month, gets thrashed about (pros, cons, etc.) until everyone losses interest and then dies the same (un implemented) death.
Jan 23 2008
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
BCS wrote:
 Reply to kede,
 
 Hi All,

 How about adding In expressions for general arrays in addition to
 assoc arrays:

 if ('i' in eyes)
 ...
 as a simple replacement for the more verbose
 foreach(c; eyes)
 if (c == 'i')
 ...
 I think its a common enough pattern to warrant inclusion?

 Have fun,
 kede

this suggestion comes up about every other month, gets thrashed about (pros, cons, etc.) until everyone losses interest and then dies the same (un implemented) death.

But the last discussion was archived in bugzilla: http://d.puremagic.com/issues/show_bug.cgi?id=1323 Summary: some people (including Walter, I believe) think that, if implemented at all, "x in some_array" should be equivalent to "x>=0 && x<some_array.length". --bb
Jan 23 2008
parent reply Michiel Helvensteijn <nomail please.com> writes:
Bill Baxter wrote:

 Summary: some people (including Walter, I believe) think that, if
 implemented at all,  "x in some_array" should be equivalent to "x>=0 &&
 x<some_array.length".

I understand that that is more efficient, but that's not the point. If you ask me, there are 'collections' of items. A set is unordered. A map can find them based on a key. An array can find them based on an index. But the focus should be on the items. So the in-operator should look for an item, not a key (or index). Well, I'm sure this argument isn't new either. :-) -- Michiel
Jan 25 2008
parent Michiel Helvensteijn <nomail please.com> writes:
Janice Caron wrote:

 So the in-operator should look for an
 item, not a key

Except that aa[key] will crash if key is not in aa, so you /really/ want to be able to test for the presence of a key in an AA.

Of course! Just not with the in-operator. -- Michiel
Jan 25 2008
prev sibling parent kede <nobody gmail.com> writes:
ah well, could be worse... could be stabbed... 

same time, next month it is then :)

BCS Wrote:

 Reply to kede,
 
 Hi All,
 
 How about adding In expressions for general arrays in addition to
 assoc arrays:
 
 if ('i' in eyes)
 ...
 as a simple replacement for the more verbose
 foreach(c; eyes)
 if (c == 'i')
 ...
 I think its a common enough pattern to warrant inclusion?
 
 Have fun,
 kede

this suggestion comes up about every other month, gets thrashed about (pros, cons, etc.) until everyone losses interest and then dies the same (un implemented) death.

Jan 23 2008
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
kede wrote:
 Hi All,
 
 How about adding In expressions for general arrays in addition to assoc arrays:
 
  if ('i' in eyes)
  ...
 
 as a simple replacement for the more verbose
  foreach(c; eyes)
    if (c == 'i')
      ...
 
 I think its a common enough pattern to warrant inclusion?
 
 Have fun,
 kede

Not as it is presented there; I may have used that pattern twice in my whole programming career (If order doesn't matter, a hashtable is a better option). If the operator returned the index (a la the standard library function find() ), it would be much more useful. But I'm fine with it being a function.
Jan 23 2008
parent bearophile <bearophileHUGS lycos.com> writes:
 How about adding In expressions for general arrays in addition to assoc arrays:
  if ('i' in eyes)


I like that, and I've said in the past.
 Not as it is presented there; I may have used that pattern twice in my 
 whole programming career (If order doesn't matter, a hashtable is a 
 better option).

For a programmer coming from Python that pattern is used all the time (even if Python has better syntaxes to define AAs). And if you look for example: 'l' in "hello" you can see that a linear scan is actually faster than a hash if the number of items is small (< ~10) (and the opApply is fast enough). That same syntax can be used to see if a substring is present in a string, and you can't do that with an hash... In my d libs there are isIn()/isInSub() functions that allow to search of an element in linear structure (arrays, AA keys, iterable objects), or to search for a subsequence. I think Tango has similar functions among its algorithms. Bye, bearophile
Jan 24 2008
prev sibling next sibling parent reply janderson <askme me.com> writes:
kede wrote:
 Hi All,
 
 How about adding In expressions for general arrays in addition to assoc arrays:
 
  if ('i' in eyes)
  ...
 
 as a simple replacement for the more verbose
  foreach(c; eyes)
    if (c == 'i')
      ...
 
 I think its a common enough pattern to warrant inclusion?
 
 Have fun,
 kede

I think something like: if (contains(eyes, 'i')) and auto value = find(eyes, 'i'); should be in the standard library. It seems excessive to put 'in' in the language. -Joel
Jan 24 2008
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
janderson wrote:
 kede wrote:
 Hi All,

 How about adding In expressions for general arrays in addition to 
 assoc arrays:

  if ('i' in eyes)
  ...

 as a simple replacement for the more verbose
  foreach(c; eyes)
    if (c == 'i')
      ...

 I think its a common enough pattern to warrant inclusion?

 Have fun,
 kede

I think something like: if (contains(eyes, 'i')) and auto value = find(eyes, 'i'); should be in the standard library. It seems excessive to put 'in' in the language.

But 'in' is already in the language. Are you suggesting it should be removed? --bb
Jan 24 2008
prev sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On Jan 25, 2008 12:10 PM, Michiel Helvensteijn <nomail please.com> wrote:
 So the in-operator should look for an
 item, not a key

Except that aa[key] will crash if key is not in aa, so you /really/ want to be able to test for the presence of a key in an AA.
Jan 25 2008