On Tue, Jun 03, 2025 at 11:54:20PM +0000, Andy Valencia via Digitalmars-d-learn wrote: > On Tuesday, 3 June 2025 at 20:51:05 UTC, Ali Çehreli wrote: > > front() does not imply an order. It will work as long as you can > > provide the elements in a sequence. The built-in associative array > > feature is an example: > > Ok, but now the data structure is told to popFront(). I completely > see how this would work for, say, slices. But when hashed, > arbitrarily large, and unordered? Not so much. > > (I know how to code this walker using generators, but that does not > play with the Range oriented API's so far as I can tell.) [...]
In general, it's a bad idea to conflate the container with the range over its elements. Built-in arrays are a bad example in this case, because they are both, and it just so happened that they work OK as such. But in general, containers should NOT be conflated with ranges. That only leads to wrong design. The correct way to do this is to create a method in the container that returns a range over its contents. Popping the range should NOT mutate the container. It should be regarded as something separate from the container. Only then will you get sane semantics. Trying to conflate an unordered container with a range will only lead to pain and bugs. T -- You have to expect the unexpected. -- RL
