std.containers - WAT

[Jonathan M Davis]

On Wednesday, March 28, 2012 16:40:56 James Miller wrote:
> On 28 March 2012 15:28, Andrei Alexandrescu
> 
> <SeeWebsiteForEmail at erdani.org> wrote:
> >> In fact, why are any of the functions accepting and
> >> returning /Ranges/ which are internal types specific to the container?
> > 
> > Ranges are not internal to containers, they are the way containers are
> > manipulated.
> 
> But there is a Range struct inside each container, it implements the
> Range interface, but as far as I am aware, it is its own type, and
> therefore anything that explicitly expects a Range is going to
> expecting its own internal type. From what I can tell, the internal
> Range struct on each container is just the underlying storage
> mechanism for that container, and you can even have more than one
> defined internal Range for a container. The issue comes about that
> several methods want that type. Now there may be some voodoo going on
> that I don't understand, but it seems to me that I can't do some thing
> like:
> 
>     SList!int s = [1,2,3,4,5,6,7];
>     s.linearRemove([4]) // Arrays are ranges
> 
> To remove a certain value, because [4] is not a valid type, despite
> the fact that isForwardRange!(int[]) returns true. This is because
> although int[] is a range, it is not a Range (as in the inner type
> inside SList named Range). This is incredibly confusing to people
> reading the documentation, since Range and range could mean anything.
> 
> I guess what I want is the why's for everything, why do things return
> certain values? Why do certain methods only accept data that was
> pulled from the container in the first place? Simply saying that some
> generally returns some value doesn't help, I need to know the whys
> behind it. Is is because the common use case is that, is it because it
> was the easiest way to do it, is it because you just randomly decided
> to because you felt that void was a cop-out?
> 
> I just feel that the documentation could do with some work in this
> regard, but I wasn't there when this was being designed, I don't know
> the whys behind the decisions. If I point out where I think the
> documentation is lacking, simply in a "That is completely useless"
> kind of way, could somebody either update the documentation, or
> provide me with better explanations.
> 
> I have also attached the screenshot you asked for, sorry for the
> quality, I don't have the tools on my machine to deal with images
> properly right now.

It's like iterators in C++. Each container has its own, and that's the type 
that you use to iterate over and manipulate the elements of a container. It's 
just that instead of using iterators, std.container is using ranges.

As to why some functions require ranges from the container specifically, it's 
for the same reason that many functions on STL containers require iterators 
from the container specifically: they need to operate on those exact elements, 
not the values of those elements or some other iterator or range which points 
to the same values. They must operate on those exact elements.

std.container still needs some work to be sure (parts of it are going to be 
redesigned to work with the custom allocators which are currently being worked 
on), and the documentation probably does need some work, but much of how it 
works is pretty much the same as how the containers work in C++.

- Jonathan M Davis