Deque impl.

[monarch_dodra]

On Thursday, 31 January 2013 at 07:34:52 UTC, d coder wrote:
>> To be honest deque can be implemented far better if random 
>> access as in
>> indexing, removal and such is dropped.
>
> As other people too pointed out, Deque is indeed a random access
> range, so indexing operator is a must. Insert/Remove too are 
> good to
> have. Array implementation in the std.container too implements 
> remove
> and insert.
>
> Another small issue is that this Deque implementation is a 
> Class.
> std.container provides all the containers as structs. So for 
> sake of
> consistency, we should implement Deque too as a struct.
>
> Regards
> - Puneet

Quite frankly, I'm bringing more and more into question the fact 
that everything in phobos are structs, especially considering the 
"no default constructor" problem.

The containers in std.container pretty much emulate final classes 
via pointers to payloads anyways. Not doing it via classes only 
brings problems.

And even if you succeed in coding the damn thing correctly 
(Objects like DList had so many bugs I consider it virtually 
unusable). The end result is subtle user bugs when passing 
containers, if they have not been initialized yet. It creates an 
ambiguity in behavior if or if not the container is initialized 
(modification to the container inside the function may or may not 
modify the outside container).

The only argument I see in favor of structs, is the possibility 
of having a deterministic memory model (std.container.Array). I 
don't think D's *generic* containers should do that though, IMO. 
It also brings lots of problems, just for a specific use case.

Long story short, I'd say that unless you have a damn good reason 
to stay with structs, use classes. It has easier user semantics 
and much less room for implementation bugs.

(PS: Argument also applies to all the PRNGs.)