Andrei Khropov wrote:
> BCS wrote:
> 
>>  if({foreach(i;a) if(i==j) return true; return false;}())
> 
> Yeah, this new delegate syntax is cool !

Wow! I didn't know you could have a naked {} like that as a void delegate. That is cool. Looks as though D has sucked all the juice out of C++, and is moving onto the scripting languages...

BCS wrote:

> the semantics are backwards, not a killer but its a little inconsistent.
> 
> With aa, the type of the LHS is the type of the index
> 
> if(a in b) b[a]; // valid
> 
> with non-aa, the type of the LHS would be the type of the stored value. The above wont always work for a non-aa. Also which a in b is found? The first? An array of all? The last?

I would be satisfied also if it just returns a boolean value, like a simple inclusion test...

But for now, I will use the BCS solutions! Thanks!

---
Paolo

BCS wrote:
> Andrei Khropov wrote:
>> Paolo Invernizzi wrote:
>>
>>
>>> Hi all,
>>>
>>> Someone can suggest me the best way for testing the presence of an element in
>>> an array?
>>>
>>> Coming from python, something like...
>>>
>>> if( x in array_of_x && y in array_of_y ){
>>>   ...
>>> }
>>>
>>> The workaround, apart from using a simple 'for' loop, is to use an
>>> associative array, and test for key...
>>>
>>> ---
>>> Paolo
>>
>>
>> Despite BCS proposed a cool solution
> 
> thanks
> 
>> I think 'in' should be built-in for usual (non-associative) arrays too. why not?
>>
>>
> 
> the semantics are backwards, not a killer but its a little inconsistent.

Yeah, some think it is some think it isn't, I think it isn't but it is an old discussion and probably one we will never agree on.

IMO:
normal arrays store *values* which are indexed by a key (index)
associative arrays store *keys* and the value is just an additional information about the key.

That is only my opinion as some people think that AA's also are about values.

Paolo Invernizzi wrote:
> BCS wrote:
> 
>> the semantics are backwards, not a killer but its a little inconsistent.
>>
>> With aa, the type of the LHS is the type of the index
>>
>> if(a in b) b[a]; // valid
>>
>> with non-aa, the type of the LHS would be the type of the stored value. The above wont always work for a non-aa. Also which a in b is found? The first? An array of all? The last?
> 
> 
> I would be satisfied also if it just returns a boolean value, like a simple inclusion test...
> 
> But for now, I will use the BCS solutions! Thanks!
> 
> ---
> Paolo
> 

That's most likely the best solution for the moment.  Although, you could generalize it by  taking advantage of IFTI and defining this somewhere:

# bool contains (T : T[]) (T[] haystack, T needle) {
#   foreach (x; haystack) {
#     static if (is(T : Object)) {
#       if (x is needle)
#         return true;
#     }
#     else {
#       if (x == needle)
#         return true;
#     }
#   }
#   return false;
# }

Then your test would just be:

# if (foo.contains(bar)) {
#   // do stuff
# }

I think it reads pretty well, even if it isn't quite as "clean" as (bar in foo) in comparison.  Which, incidentally, also does read well.

-- Chris Nicholson-Sauls

Ivan Senji wrote:

> 
> Yeah, some think it is some think it isn't, I think it isn't but it is an old discussion and probably one we will never agree on.
> 
> IMO:
> normal arrays store values which are indexed by a key (index)
> associative arrays store keys and the value is just an additional information
> about the key.
> 
> That is only my opinion as some people think that AA's also are about values.

AA is also often called dictionary or map (in STL for example).

If you speak about some kind of collection where only value (and its presense or absense in the collection) is important it's probably better to call it a set.

-- 

Don Clugston wrote:
> Andrei Khropov wrote:
> 
>> BCS wrote:
>>
>>>  if({foreach(i;a) if(i==j) return true; return false;}())
>>
>>
>> Yeah, this new delegate syntax is cool !
> 
> 
> Wow! I didn't know you could have a naked {} like that as a void delegate. That is cool. Looks as though D has sucked all the juice out of C++, and is moving onto the scripting languages...
> 

Not quite naked, without the ending () the type is "bool delegate(void)" a.k.a. always true.

Andrei Khropov wrote:
> Ivan Senji wrote:
> 
> 
>>Yeah, some think it is some think it isn't, I think it isn't but it is an old
>>discussion and probably one we will never agree on.
>>
>>IMO:
>>normal arrays store values which are indexed by a key (index)
>>associative arrays store keys and the value is just an additional information
>>about the key.
>>
>>That is only my opinion as some people think that AA's also are about values.
> 
> 
> AA is also often called dictionary or map (in STL for example).
> 
> If you speak about some kind of collection where only value (and its presense
> or absense in the collection) is important it's probably better to call it a
> set.
> 

How about allow void[TYPE]? No values, only keys.

void[char[]] whos;

... // fill whos

if("Bob" in whos) Hire("Bob");
if("Capone" in whos) whos.remove("Capone");
whos["Bubba"];	// add Bubba

auto him = whos["Bubba"];	// can't do that with a void

// ( or

auto him = whos["Bubba"];	// == bool.true
auto who = whos["Capone"];	// == bool.false

// )

BCS wrote:

> Don Clugston wrote:
>> Andrei Khropov wrote:
>> 
>>> BCS wrote:
>>>
>>>>  if({foreach(i;a) if(i==j) return true; return false;}())
>>>
>>>
>>> Yeah, this new delegate syntax is cool !
>> 
>> 
>> Wow! I didn't know you could have a naked {} like that as a void delegate. That is cool. Looks as though D has sucked all the juice out of C++, and is moving onto the scripting languages...
>> 
> 
> Not quite naked, without the ending () the type is "bool delegate(void)"
> a.k.a. always true.

The () is for calling it, {} is fine if you want pass (what I would call
naked) a delegate to a function taking delegates as arguments.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

BCS escribió:
> Andrei Khropov wrote:
>> Ivan Senji wrote:
>>
>>
>>> Yeah, some think it is some think it isn't, I think it isn't but it is an old
>>> discussion and probably one we will never agree on.
>>>
>>> IMO:
>>> normal arrays store values which are indexed by a key (index)
>>> associative arrays store keys and the value is just an additional information
>>> about the key.
>>>
>>> That is only my opinion as some people think that AA's also are about values.
>>
>>
>> AA is also often called dictionary or map (in STL for example).
>>
>> If you speak about some kind of collection where only value (and its presense
>> or absense in the collection) is important it's probably better to call it a
>> set.
>>
> 
> How about allow void[TYPE]? No values, only keys.
> 
> void[char[]] whos;
> 
> .... // fill whos
> 
> if("Bob" in whos) Hire("Bob");
> if("Capone" in whos) whos.remove("Capone");
> whos["Bubba"];    // add Bubba
> 
> auto him = whos["Bubba"];    // can't do that with a void
> 
> // ( or
> 
> auto him = whos["Bubba"];    // == bool.true
> auto who = whos["Capone"];    // == bool.false
> 
> // )

It was possible some time ago, but it got forbidden. What I've been doing (and I think others too) is:

char [] [char []] whos;

And set the element to both the key and the value. However, I admit I liked void [T].

-- 
Carlos Santander Bernal

On Sat, 15 Jul 2006 02:46:24 +1000, Carlos Santander <csantander619@gmail.com> wrote:


>
> It was possible some time ago, but it got forbidden. What I've been doing (and I think others too) is:
>
> char [] [char []] whos;
>
> And set the element to both the key and the value. However, I admit I liked void [T].

Actually I use

  bool[ char[] ] whos;

  whos["Capone"] = true;



-- 
Derek Parnell
Melbourne, Australia