Sets

[Michiel]

> The lack of a set type and the use of void[KeyType] for sets has been
> discussed a few times in the past, I think.  It makes sense to me too,
> at first glance.  But I suspect it would require a whole different
> codepath in the compiler to deal with because you can't have arrays of
> voids etc. You really want a different data structure to store a set.

I think creating a whole different data structure just for the set isn't worth the
trouble.

For now, I've created the following simple code, which I will use for now. It
still uses dummy values, but hides this behind a template and an array function:

---------------------------------
template Set(T) {
	alias bit[T] Set;
}

void add(T)(inout bit[T] set, T element) {
	set[element] = 1;
}
---------------------------------
Set!(char[]) set;

set.add("one");
set.add("two");

assert("one" in set);
assert("two" in set);
assert(!("fortytwo" in set));
---------------------------------

> And as you mentioned it should have an 'add' method which would be
> meaningless for ordinary AA's.

For ordinary AA's, another parameter could be passed for the value, which could
default to the type's init value.

> Following AA syntax could also lead to
> annoying special cases for generic templates that would have to be
> prepared for the V==void case:
>     foo(K,V)(V[K] aa) { ...V val; // whoops V could be void! }

Isn't the same thing true for many situations? What if you wanted to compare a V
object with an integer? The compiler would generate an error for any V for which
no such comparison is defined. I would simply expect the compiler to complain in
your example.

I'm not saying it's easy. But it should be worth it for the same reason that
associative arrays are included into the core language.