https://issues.dlang.org/show_bug.cgi?id=13590
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from [email protected] --- (In reply to Walter Bright from comment #0) > In using http://dlang.org/phobos/std_stdio.html#.File.byChunk, it turns out > to be rather clumsy to get things character-by-character, one has to write a > loop. This is not how ranges are supposed to work. Yeah, somebody in learn recently asked how to read a file character by character or byte by byte. I also realized we provide no D interface for that, let alone range interface. > It exposes a more general problem - given a Range of a Range of Elements, > how does one iterate over Elements? > > The solution is a new algorithm - iterate. > > And that's all it does - one could write .byChunk.iterate and voila! one is > getting ubytes by ubyte. std.algorithm.joiner does exactly that. auto joiner(RoR)(RoR r) > iterate takes a template argument of the number of > Elements it should produce for each front(): > > .byChunk.iterate!4 // get ubyte[4] > > iterate should produce results by value, not by ref. This is because byChunk > produces references to ephemeral data. byChunks also does this, with the slight differences that: 1) It is a run-time length 2) It returns a sub-range, rather than a static array That said, by a "byStaticChunk" sounds like a good idea? Either way I think it is better to compose ranges with individual jobs, rather than trying to have a single range do 2 different jobs. I'd just worry a bit if anybody asked for byStaticChunks!1024, performance wise, what with us returning a static array and all... > iterate asserts if the number of elements does not evenly divide into the > .byChunk size (or should it throw?). Obviously, by 1 should not assert or > throw. I think that's a bad idea: If you are reading your file (input range) 4 bytes by 4 bytes, how do you know ahead of time, that it will have %4 elements? And even if you know ahead of time your file is 251 bytes big, then what? Maybe instead returning a Tuple!(T[N], uint size) could be a better idea? --
