kede wrote:
> if ('i' in eyes)
> ...
> > as a simple replacement for the more verbose
> foreach(c; eyes)
> if (c == 'i')
> ...
I want to add few things to this discussion:
- D already has opIn and opIn_r, so it's just a matter of using it.
- If you use a language with the in built in (D has it already, but I meant for arrays), like Python, you can quickly understand why it's very good to have it built-in. (Generally if you come from a language that lacks something, then it becomes less easy to see why/where it's useful. I know some things aren't good if you put them in another language, but it's not this situation, I think).
- Using the foreach(c; eyes) if (c == 'i'){} pattern is bad because you always use a O(n) scan regardless what that "eyes" is. But maybe "eyes" is an object with a opIn_r method that is O(ln n) or O(1), and you miss it. Instead if you use "in" (that is you use opIn_r) you always use the faster way of finding the presence of an item the object allows you to (if no opIn_r is defined, but opApply is defined, then the "in" operator must automatically call opApply to perform a scan).
- So using "in" makes code shorter, more flexible, more type-agnostic (generic), simpler to read, potentially faster and more standard :-)
Bye,
bearophile

On Jan 25, 2008 7:25 AM, bearophile <bearophileHUGS@lycos.com> wrote:
> - So using "in" makes code shorter, more flexible, more type-agnostic (generic), simpler to read, potentially faster and more standard :-)
All good points. But I know that part of the reason it's a no-go is consistency. "in" has to scan the keys, not the values, or it would be inconsistent with AAs.
Personally I wouldn't mind dropping "in" in favor of two new infix functions "contains" and "containsKey", which would disambiguate the two cases (and give extra functionality for AAs). But it's probably too late to change things now, so forget I said anything. :-)

Janice Caron wrote:
> On Jan 25, 2008 7:25 AM, bearophile <bearophileHUGS@lycos.com> wrote:
> >>- So using "in" makes code shorter, more flexible, more type-agnostic (generic), simpler to read, potentially faster and more standard :-)
> > > All good points. But I know that part of the reason it's a no-go is
> consistency. "in" has to scan the keys, not the values, or it would be
> inconsistent with AAs.
>
Which doesn't stop Python from doing it this way. And it makes perfect sense. In an AA, you are typically concerned with whether a given key exists in the container. With an array, you are typically concerned with whether a given item is somewhere in the array. Arrays and associative arrays are fundamentally different, and I'm not sure this consistency actually buys us anything.
And, obviously, using 'in' to check whether a given index is in an array is basically useless. Using it as a containment check is /much/ more useful. So what if arrays and AAs act differently? You can't assign to an arbitrary non-existent index in an array, or append to an AA, either. They are not substitutes for each other.
> Personally I wouldn't mind dropping "in" in favor of two new infix
> functions "contains" and "containsKey", which would disambiguate the
> two cases (and give extra functionality for AAs). But it's probably
> too late to change things now, so forget I said anything. :-)
These can already be done as library functions, if there's that much concern about it.
--
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org

bearophile wrote:
> kede wrote:
>> if ('i' in eyes)
>> ...
>>>> as a simple replacement for the more verbose
>> foreach(c; eyes)
>> if (c == 'i')
>> ...
> > I want to add few things to this discussion:
> - D already has opIn and opIn_r, so it's just a matter of using it.
> - If you use a language with the in built in (D has it already, but I meant for arrays), like Python, you can quickly understand why it's very good to have it built-in. (Generally if you come from a language that lacks something, then it becomes less easy to see why/where it's useful. I know some things aren't good if you put them in another language, but it's not this situation, I think).
> - Using the foreach(c; eyes) if (c == 'i'){} pattern is bad because you always use a O(n) scan regardless what that "eyes" is. But maybe "eyes" is an object with a opIn_r method that is O(ln n) or O(1), and you miss it. Instead if you use "in" (that is you use opIn_r) you always use the faster way of finding the presence of an item the object allows you to (if no opIn_r is defined, but opApply is defined, then the "in" operator must automatically call opApply to perform a scan).
> - So using "in" makes code shorter, more flexible, more type-agnostic (generic), simpler to read, potentially faster and more standard :-)
> > Bye,
> bearophile
bool has(T)(T[] arr, T elem) {
foreach (a; arr) if (a == elem) return true;
return false;
}
if (myarray.has(3)) {
// ...
}
Just as good, imhoe. You can't avoid a linear scan unless you know whether the array is sorted.