On Monday, 7 May 2012 at 05:54:04 UTC, Jonathan M Davis wrote:
On Monday, May 07, 2012 06:49:00 Russel Winder wrote:
Any language with which the programmer has to develop their
own set implementation is sadly lacking.
It is true that set can be implemented using a map, but this
should be seen as implementation detail, not as programmer
level tool. It indicates that set should exist where set does.
So for C++ it is in the standard library, for Python it is a
built-in (*).
The conclusion for D is straightforward. Which issue to I go
to to vote?
We have RedBlackTree, so we have a set already. What we don't
have is a HashSet. However, once the custom allocator stuff has
been sorted out, I'd fully expect to have one in std.container
along with a variety of other container types which we really
should have but don't.
Been thinking about this a little. With arrays, fixed arrays and
associative arrays being built in, you don't need set to be built
in. First it's already hash-map like so it's going to be O(1),
and the data being kinda useless can either be a byte, and int
(offset to an array perhaps), or to itself.
It has the added benefit of being a sparse array when asked of
it. So aside from a slight loss in memory space which is only
going to be critical in embedded systems. The only thing the
builtins don't offer is a way to automatically sort the data,
which the libraries and RedBlackTree's do quite well so far as I
can see.
