Removing from SList (std.container)...

[Jonathan M Davis]

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