New set class

[Michiel]

Frits van Bommel wrote:

>> Yes, this does make sense. But my set implementation doesn't provide any
>> write access to its members anyway, so you could say that everything you
>> put into it automatically becomes 'frozen'.
> 
> Actually, the frozenset type doesn't allow things like add() and
> remove(). And both set and frozenset disallow changing the elements.
> At least, according to the page he linked.

Yes, I meant the elements of the set ('everything you put into it').

> This may just be more trouble than it's worth. Perhaps you should just
> say that things can get really screwed up if you change elements of a
> set...

I think I will. Since that's how D handles this problem at the moment.

>> How does D handle this with its associative arrays?
> 
> <SNIPPYSNAPSNAP>
> 
> So yeah, don't change AA keys.

Hm.. This is not a good thing. I'm not saying I have the perfect
solution, but this is not a good thing.

>> You know, I liked C++ better in that regard. If you do an assignment or
>> pass something as an argument it's automatically a copy. In Java and in
>> D you have to explicitly copy something, except if it's a base type. I
>> don't like exceptions like that.
> 
> IIRC there have been suggestions to add .dup to base types that just
> returns their value, for use in generic programming (i.e. templates).

Well, that would be a start. :) But I'd still like the C++ way better.
It could still have Java-style references, but the copy behavior isn't
necessary.

-- 
Michiel