Sets

[Bill Baxter]

Michiel wrote:
> Sean Kelly wrote:
> 
>> The behavior for sets was cleaner before their behavior was changed such
>> that an opIndex lookup throws an exception if the lookup fails.
>> Previously, it would return the default value, which for bool would be
>> 'false'.  Insertions were still a bit messy as setName[key] = true, but
>> it was better than nothing.  Personally, I'm not fond of how AA indexing
>> and 'in' works now.  It feels like a kludge.
> 
> Ah, I see. I understand how the old behavior was handy for faking sets. But to be
> honest, I like the new behavior better in general. That old behavior was much more
> ambiguous. And the 'in' notation is more intuitive for people with a background in
> basic set theory.
> 
> My problems are:
> * Declaring the set: You have to give a value type, even though you don't really
> need it.
> * Adding to the set: You have to assign a dummy value, which isn't very elegant.
> 
> I think the void[KeyType] notation for sets is very intuitive. All it further
> needs is an add(KeyType element) function. I think it can be well defined and
> would be a nice addition to the D language.
> 
> Do the D developers read this newsgroup? Or should I mail them with this suggestion?

Walter reads this newsgroup, so there's nothing in particular you need 
to do.

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. 
And as you mentioned it should have an 'add' method which would be 
meaningless for ordinary AA's.  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! }

Anyway, all that says to me that void[KeyType] for sets is not really a 
slam dunk, and a simple set() class in the std library might be a better 
option.

I'm surprised Sean didn't mention it, but the Tango replacement for the 
standard library does have Set as well as Bag (aka "multi-set") 
collection types.

--bb