[Issue 13409] std.range.padLeft/Right
via Digitalmars-d-bugs
digitalmars-d-bugs at puremagic.com
Sun Aug 31 14:32:49 PDT 2014
https://issues.dlang.org/show_bug.cgi?id=13409
--- Comment #2 from Peter Alexander <peter.alexander.au at gmail.com> ---
(In reply to monarchdodra from comment #1)
> Is there a use case for this outside of string formatting?
I need it for padding data buffers out.
> Also, does it justify having a new range, when the same end result could be
> had with chain and repeat?
I think it is justified. When using chain/repeat, it isn't immediately clear
what you are doing, whereas padLeft/Right are self documenting. If I needed to
do this, I would create padLeft/Right myself as separate functions to make it
clear. If people are going to do this then it might as well be in Phobos, in my
opinion.
Also, padRight with an input range without length cannot be implemented in
terms of other ranges, I think (not easily anyway).
I actually only need padRight, but I feel padLeft should exist for symmetry.
> For padLeft, I'm making the assumption that r is random access. If we want
> to accept forward range (input is not possible), then we have to use
> r.save.walkLength(), presuming the extra complexity is acceptable.
>
> The only case where your proposal could make sense, is for padRight on a
> pure input range (no length, no save). But that's one hell of a particular
> case...
Random access is unnecessary. You only need hasLength + input range (see
proposal). Incidentally, these kind of subtleties are a good reason why Phobos
should provide them instead of relying on users to do so.
The case for input range with no length for padRight is actually exactly what
prompted me to create this. I'm generating some data of unknown length (it is
lazily generated) that I want to copy into a pre-sized buffer, and then fill
the rest of the buffer with 0's.
--
More information about the Digitalmars-d-bugs
mailing list