Shouldn't SList in std.container hold an owner pointer to verify a range belongs to the list?

[monarch_dodra]

On Monday, 16 December 2013 at 21:57:52 UTC, Andrej Mitrovic 
wrote:
> Here's some improper code that is not checked properly by SList
> (meaning no assertions, not even in debug mode):
>
> -----
> import std.stdio;
> import std.container;
>
> void main()
> {
>     auto s1 = SList!string(["a", "b", "d"]);
>     auto s2 = SList!string(["a", "b", "d"]);
>
>     // note the s1[] instead of s2[]!
>     s2.insertAfter(std.range.take(s1[], 2), "c");
>
>     writeln(s1[]);  // updated s1, not s2!
>     writeln(s2[]);  // s2 stays the same.
> }
> -----
>
> Note the docs of insertAfter:
>
> Inserts $(D stuff) after range $(D r), which must be a range
> previously extracted from this container.
>
> Well clearly we have a range extracted from one list being used 
> to add
> items to a different list, but SList makes no checks at all to 
> verify
> the range belongs to it. I had a look at DCollections[1], and it
> stores an "owner" pointer (or reference) in the range type when 
> its
> extracted from a linked-list, so it can do these types of sanity
> checks.
>
> So shouldn't we add this to SList? We'd have to add an owner 
> field to
> its internal "Range" struct.
>
> [1] : https://github.com/schveiguy/dcollections

Didn't I reply to this already?

Anyways... what I said is that we can add the test in 
non-release, but I see it as assertive code, so it can be removed 
in release.

I'd be more afraid of DList's current semantics: Neither value 
nor ref. I've been trying to fix it for more than a year now:

https://github.com/D-Programming-Language/phobos/pull/953