Time for 2.067

[via Digitalmars-d]

On Friday, 30 January 2015 at 23:17:09 UTC, Andrei Alexandrescu 
wrote:
> Sorry, I thought that was in the bag. Keep current semantics, 
> call it chunkBy. Add the key to each group when the predicate 
> is unary. Make sure aggregate() works nice with chunkBy().

I might miss some information on this, so please forgive my naive 
question. Your requirements seem to be contradictory to me.

1. aggregate expects a range of ranges
2. you ask chunkBy to return something that is not a range of 
ranges
3. you ask chunkBy to play along nicely with aggregate

There are certainly ways to make this work. Adding a special 
version of aggregate comes to mind. However, I fail to see the 
rational behind this.

To me the beauty of range is the composibility of "simple" 
constructs to create complex behavior. The current chunkBy does 
not need to be changed to "add the key to each group when the 
predicate is unary":

  r.map!(pred, "a")
   .chunkBy!("a[0]")
   .map!(inner => tuple(inner.front[0], inner.map!"a[1]"));

So I'd like to know why the above is inferior to a rework of the 
chunkBy's implementation. Maybe this is a question for D.learn.