Hasan Aljudy skrev:
> Please guys .. let's not try to put everything in the language. It all can be implemented using classes (and templates, if you really want).
> 
> Building everything into D will just turn D into another C++. What I mean is, it'll become a kludge.
> <snip>

I agree, no need to add stuff for the sake of adding. But there are many reasons not to put it is a library. First of all it a so simple and basic data type, that if put in a library you might as well throw arrays in there (An array is an ordered list of values, a set is an unordered list without dublicates). Secondly hiding a feature this good in a library will hide it from many users, just as Walter argued on regexes and added match expressions. And thirdly, as a first class sitizen in the language the compiler can do wonders with it.

But letts look at the overview page of D, and the major goals (top 1):

* Reduce software development costs by at least 10% by adding in proven
  productivity enhancing features and by adjusting language features so
  that common, time-consuming bugs are eliminated from the start.

Check on all accounts. Far less code to write (less code==less bugs). Sets solves a problem domain that normaly requires many, many lines of code, some loops, nested ifs and a general mess.

I think the reason som people do not use regex or associative arrays is that they simply have not tried them, and understood just how useful they are. I sure know that everyone I have introduced to regex, associative arrays AND sets have never understood how they could code without thm before.

// Fredrik

Fredrik Olsson wrote:

> Well, with so much talk of features in (regexp) and out (bit), why not
> bring up my favourite yet again: the sets!

There are sets in D _almost_ avaiable today. We could have sets as associative arrays:

void[int] set_of_ints;
void[Car] set_of_cars;

and use them as usual:

Car ferrari = new Car("ferrari F50");

if (ferrari in set_of_cars) {
  writef("you've got a ferrari. wow - you're lucky.\n");
} else {
  set_of_cars.insert(ferrari);
  writef("I will give you mine ferrari.\n");
}


Not much to change, lot to gain. The only real problem was inserting into such array. Just ask Walter to let this work well. I remember having some difficulties and using bit[int] to achive this in my app.

> How about in for arrays for consistency with AA's:
>
> void foo(char[] )
> {
> char[] arr = "abcdef";
> //...
> if('d' in arr) { ... }
> }
>

NO! Please don't do this. The operation is O(n). If will be useful perhaps for "if (day in Weekdays)", but the system is extremely unscalable, and using "in" on a larger array will harm performance. I don't think it's a good idea to hide such a potential performance hit behind a small word like "in".

(In fact, I generally think the costly operations should get long, complicated names, so they don't get used too often)

Now if the array were sorted, one could do a binary search, which is not all too bad. But this still needs special syntax, since the compiler should enforce the sorting.

L.

Lionello Lunesu wrote:
>>How about in for arrays for consistency with AA's:
>>
>>void foo(char[] )
>>{
>>char[] arr = "abcdef";
>>//...
>>if('d' in arr) { ... }
>>}
>>
> 
> 
> NO! Please don't do this. The operation is O(n). If will be useful perhaps for "if (day in Weekdays)", but the system is extremely unscalable, and using "in" on a larger array will harm performance. I don't think it's a good idea to hide such a potential performance hit behind a small word like "in".
> 
> (In fact, I generally think the costly operations should get long, complicated names, so they don't get used too often)
> 
> Now if the array were sorted, one could do a binary search, which is not all too bad. But this still needs special syntax, since the compiler should enforce the sorting.
> 

O(n) can be an expensive operation, but if used with arrays with less then 10 elements, it would not only be simpler to code, but also almost as fast as any other search algorithm. Very often i have such small arrays and having to do:
bool foundit=false;
foreach(....){if(...)foundit=true;}

is not only as equally efficient but also much harder to write.

Not having in operator for arrays because of O(n) is like saying vector<int> in C++ is bad because you can have milions of elements and linear search is slow. It is all about choosing the right tool for the job. If someone want's a container with many elements he will probably use a container implementning binary search or some other faster element, but in many cases simple linear search in a couple of elements is more than enough.

One thing that would be very nice is having overloadable in operator for user defined types.

PS Another positive side about having in for arrays would be consistency, we have it for AA's, having it for normal arrays and classes would just make it make more sence to have.

>> How about in for arrays for consistency with AA's:
>>
>> void foo(char[] )
>> {
>> char[] arr = "abcdef";
>> //...
>> if('d' in arr) { ... }
>> }
>>
>
> NO! Please don't do this. The operation is O(n). If will be useful perhaps for "if (day in Weekdays)", but the system is extremely unscalable, and using "in" on a larger array will harm performance. I don't think it's a good idea to hide such a potential performance hit behind a small word like "in".
>
> (In fact, I generally think the costly operations should get long, complicated names, so they don't get used too often)
>
> Now if the array were sorted, one could do a binary search, which is not all too bad. But this still needs special syntax, since the compiler should enforce the sorting.

I disagree.  The linear search would be adequate for most problems. Typically "in" is merely used instead of an "if(x == a || x == y || x == z ...)", which is also a linear search.  If you need a binary search then you can use a different syntax for that.

-Craig