On Wednesday, 27 June 2012 at 21:38:28 UTC, Jonathan M Davis wrote:
> On Wednesday, June 27, 2012 22:29:01 Roman D. Boiko wrote:
>> On Wednesday, 27 June 2012 at 20:14:53 UTC, Steven Schveighoffer
>> 
>> wrote:
>> > Removal of that element is perfectly possible, you just need to
>> > maintain a reference to its predecessor. Which SList's range
>> > does not keep track of. It all depends on tradeoffs of what
>> > you want for performance, vs. features. It's why I contend
>> > that generic singly linked list is difficult to create. Can't
>> > please everyone.
>> 
>> Yes, I agree.
>> 
>> > And iterators are not necessary, ranges are quite possible.
>> 
>> In this respect it is not only a performance vs. features
>> tradeoff, semantics is (usually) different. Of course, we might
>> use a range for what is semantically an iterator. But it feels
>> unnatural for me.
>> 
>> E.g., to point to an element in the middle of some range we would
>> need to create another range and pass it to a function along with
>> the original range. I would hesitate to call them ranges unless
>> that is explicitly a goal for some particular application. If
>> that was the case, it would require an explicit explanation. (IMO)
>
> If you want a single element, then use take, takeExactly, or takeOne. For
> instance, that's what you do when you want to use remove in std.container
> (though apparently takeOne was missed as pointed out earlier in this thread,
> which needs to be remedied). It is true that dealing with ranges in this sort
> of situation is a bit more problematic than it is with iterators, but the
> take* functions take care of it as long as the container properly takes them
> into account (which std.container's containers are supposed to do). And if all
> you care about is having a range with one element and not whether the range is
> passable to a function on it's associated container, then the take* functions
> work just fine regardless of whether the container properly takes them into
> account. It's only an issue with the container, because the container needs
> its original range type rather than some arbitrary range which may have
> nothing to do with that container (the same happens with iterators - you just
> don't tend to wrap them in other types in the same way that happens with
> ranges).
>
> - Jonathan M Davis

It depends entirely on intended semantics and use cases. There is a difference between a range, an iterator, and a link (pointer) to some container node. I meant a link when I used the term "iterator".

To illustrate, imagine a tree container. A link could point to some node, which could be used conceptually as a container. A range would define a subset of either element values or links for some traversal. So a range semantically implies an ordering, and is quite different from a link. An iterator seems to be closer to a range in this respect, that's why I admitted that I used the term incorrectly.

Doesn't Andrei plan to do something about this module?

On Thursday, June 28, 2012 00:23:03 Minas Mina wrote:
> Doesn't Andrei plan to do something about this module?

He came up with the basic design, and he's working on the custom allocator design. Once that's been sorted out, std.container will be made to use it, and more containers will be added to it. We're trying to avoid having to implement the containers twice (as would happen to at least some extent if we added them all and then added the custom allocators later), which is why there aren't more of them yet. But Andrei has been very busy, so progress has been slow, and I don't know where he stands with it right now.

- Jonathan M Davis

Am 27.06.2012 14:25, schrieb Steven Schveighoffer:
> On Wed, 27 Jun 2012 05:37:00 -0400, Minas Mina
> <minas_mina1990@hotmail.co.uk> wrote:
>
>> How can I do that?
>>
>> Why not list.remove(x); like in STL?
>
> SList is quite unusable.
>
> If you are looking for STL-like containers, there is dcollections which
> has a doubly-linked list, and supports syntax like you want.
>
> http://www.dsource.org/projects/dcollections
>
> -Steve

I Wish dcollections has been part of Phobos 2 years ago.
But thanks to the ongoing one man show (even being absent does not help ) ,  Library development is more or less stalled.  Don't believe ? Github Phobos.

What is the problem in creating  some very simple structures. Queues, Deques,  Stacks. create a thread safe version, fine.  None of these structures have a need for ranges, respective special allocating ,at all THESE structures have a very clear and limited job.

struct Queue(T)
{
	DeQueue() {}
	EnQueue() {}


	struct Node // double linked list node
	{
		T data;

		Node* next;
		Node* previous;

		this (..........)
		{

		}
}

And in case that you don't like that..
struct Queue(T, alias Alloc){} ..
But who cares 'cause the very first queue implementation in Phobos will be in 2017.

I've tried (while becoming very unpopular) to encourage you to stop that  "waiting for Andrej nonsense, but you behave like Lemmings....

I followed D now for 5.5 years and all I'd like to say now is :
Give up your efforts.
You folks have wasted enough foreign time and audience.

Bjoern Lietz-Spendig