www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - !in operator?

reply Jeremie Pelletier <jeremiep gmail.com> writes:
Why is there no !in operator just like there is a !is operator?
Is it because this expression evaluates to a pointer to the found element? Even
so, it would make asserts much easier to write.
May 22 2009
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Jeremie Pelletier wrote:


 Why is there no !in operator just like there is a !is operator?
 Is it because this expression evaluates to a pointer to the found element?
 Even so, it would make asserts much easier to write.


That is unfortunately a rather sticky point.  The in operator does not 
return bool.  I think the lack of !in is to encourage writing of efficient 
code.  I'm not really sure though.
May 22 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Jason House:

 The in operator does not 
 return bool.  I think the lack of !in is to encourage writing of efficient 
 code.  I'm not really sure though.


Lot of time ago I have said I'd like !in, I'm waiting for it still.

Bye,
bearophile
May 22 2009
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Jason House wrote:
<snip>

 That is unfortunately a rather sticky point.  The in operator does not 
 return bool.  I think the lack of !in is to encourage writing of efficient 
 code.  I'm not really sure though.


How, exactly, does not having !in make code efficient?

Stewart.
May 24 2009
parent reply Jason House <jason.james.house gmail.com> writes:
Stewart Gordon Wrote:


 Jason House wrote:
 <snip>

 That is unfortunately a rather sticky point.  The in operator does not 
 return bool.  I think the lack of !in is to encourage writing of efficient 
 code.  I'm not really sure though.


 
 How, exactly, does not having !in make code efficient?
 
 Stewart.


Consider the following code snippets:

Method 1:

if (x !in y)
  foo();
else{
  auto z = x in y;
  bar(z);
}

Method 2:

auto z = x in y;
if (z is null)
  foo;
else
  bar(z);

Method 1 essentially calls in twice while method 2 calls in once.

PS: Please don't assume that I'm advocating not having a !in operator. I'm just
pointing out possible reasons it may have been avoided.
May 24 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Jason House:

 Method 1 essentially calls in twice while method 2 calls in once.


Sometimes I just want to know if something isn't present.
Having !in doesn't prevent me from writing and using x = y in aa; when I want
it.



 PS: Please don't assume that I'm advocating not having a !in operator. I'm
just pointing out possible reasons it may have been avoided.<


I think that's not a possible reason :-)

Bye,
bearophile
May 24 2009
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Jason House wrote:
<snip>

 Method 1:
 
 if (x !in y)
   foo();
 else{
   auto z = x in y;
   bar(z);
 }
 
 Method 2:
 
 auto z = x in y;
 if (z is null)
   foo;
 else
   bar(z);
 
 Method 1 essentially calls in twice while method 2 calls in once.


<snip>

But there's no requirement to look it up after finding out whether it's 
there or not.

And how's it any different from

if (x in y) {
     auto z = x in y;
     bar(z);
} else {
     foo();
}

or even

if (x in y) {
     bar(y[x]);
} else {
     foo();
}

?

Besides, why would any decent compiler not optimise it to a single lookup?

Stewart.
May 24 2009
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Stewart Gordon wrote:

 Jason House wrote:
 <snip>

 Method 1:

 if (x !in y)
   foo();
 else{
   auto z = x in y;
   bar(z);
 }

 Method 2:

 auto z = x in y;
 if (z is null)
   foo;
 else
   bar(z);

 Method 1 essentially calls in twice while method 2 calls in once.


 <snip>
 
 But there's no requirement to look it up after finding out whether it's 
 there or not.
 
 And how's it any different from
 
 if (x in y) {
     auto z = x in y;
     bar(z);
 } else {
     foo();
 }
 
 or even
 
 if (x in y) {
     bar(y[x]);
 } else {
     foo();
 }
 
 ?
 
 Besides, why would any decent compiler not optimise it to a single lookup?


Interesting fact: LDC currently optimizes the first case (at -O3), but not the 
second. That's because it apparently uses a different libcall for 'x in y' than 
it does for 'y[x]' -- even though the code in the libcalls are equivalent.

I think I just found inspiration for my next commit :).
May 25 2009
parent Leandro Lucarella <llucax gmail.com> writes:
Frits van Bommel, el 25 de mayo a las 12:37 me escribiste:

 Stewart Gordon wrote:

Jason House wrote:
<snip>

Method 1:

if (x !in y)
  foo();
else{
  auto z = x in y;
  bar(z);
}

Method 2:

auto z = x in y;
if (z is null)
  foo;
else
  bar(z);

Method 1 essentially calls in twice while method 2 calls in once.


<snip>
But there's no requirement to look it up after finding out whether it's there
or not.
And how's it any different from
if (x in y) {
    auto z = x in y;
    bar(z);
} else {
    foo();
}
or even
if (x in y) {
    bar(y[x]);
} else {
    foo();
}
?
Besides, why would any decent compiler not optimise it to a single lookup?


 
 Interesting fact: LDC currently optimizes the first case (at -O3), but not the
second. That's because it apparently uses a different libcall for 'x in y' than 
 it does for 'y[x]' -- even though the code in the libcalls are equivalent.
 
 I think I just found inspiration for my next commit :).


He is not joking:
http://www.dsource.org/projects/ldc/changeset/1418%3Af5f8c21ce6ef

Thank you =)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Ladrón no es cualquiera, ladrón es quien usurpa el bien ajeno en
beneficio propio, si no, no.
	-- Ricardo Vaporeso
May 25 2009
prev sibling next sibling parent downs <default_357-line yahoo.de> writes:
Jeremie Pelletier wrote:

 Why is there no !in operator just like there is a !is operator?
 Is it because this expression evaluates to a pointer to the found element?
Even so, it would make asserts much easier to write.


http://dsource.org/projects/scrapple/browser/trunk/tools/tools/base.d

tools.base.notin :)

if (foo /notin/ bar) { ... }
May 23 2009
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Jeremie Pelletier wrote:

 Why is there no !in operator just like there is a !is operator? Is it 
 because this expression evaluates to a pointer to the found element? 


<snip>

Of course not.  This compiles:

void main() {
     char* abc;
     assert (!abc);
}

so why shouldn't !in?

Stewart.
May 24 2009