Deque impl.

[Robert burner Schadek]

On 01/31/2013 09:46 AM, monarch_dodra wrote:
> 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.)
I can only agree