why allocators are not discussed here

[Adam D. Ruppe]

So to try some ideas, I started implementing a simple container 
with replaceable allocators: a singly linked list.

All was going kinda well until I realized the forward range it 
offers to iterate its contents makes it possible to escape a 
reference to a freed node.

auto range = list.range;
auto range2 = range;
range.removeFront();

range2 now refers to a freed node. Maybe the nodes could be 
refcounted, though a downside there is even the range won't be 
sharable, it would be a different type based on allocation 
method. (I was hoping to make the range be a sharable component, 
even as the list itself changed type with allocators.)

I guess we could @disable copy construction, and make it a 
forward range instead of an input one, but that takes some of the 
legitimate usefulness away.

Interestingly though, opApply would be ok here, since all it 
would expose is the payload.

(though if the payload is a reference type, does the container 
take ownership of it? How do we indicate that? Perhaps more 
interestingly, how do we indicate the /lack/ of ownership at the 
transfer point?)



This is all fairly easy if we just decide "we're going to do this 
with GC" or "we're going to do this C style" and do the whole 
program like that, libraries and all. But trying to mix and match 
just gets more complicated the more I think about it :( It makes 
the question of "allocators" look trivial.