[Issue 10868] std.string.translate should take an optional buffer

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=10868


monarchdodra at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |monarchdodra at gmail.com


--- Comment #6 from monarchdodra at gmail.com 2013-08-25 01:53:53 PDT ---
(In reply to comment #3)
> IIRC, it's come up before (with the digest stuff? - I know the issue of a
> function to "finish" came up for that), but I don't recall any resolution of
> it.

I remember having brought up the subject a few times before. It never gets
discussed a whole lot though. The latest is here:
http://forum.dlang.org/thread/gqsfiatbhdqwcptkoqua@forum.dlang.org

> I believe that with regards to arrays at least, if you use them as an
> output range, you can check for full by checking that length != 0, and length
> effectively ends up giving you how much left you can write to, but even if that
> holds in general, not all ranges can tell you how much they can be written to
> them as opposed to whether they're full, which IIRC led to discussions of the
> case where you try and put more elements than can fit at once (e.g. if you have
> 1 char left in a char[] and try and put a character takes up 3 code units), and
> that almost requires that you end up throwing in put in some cases rather than
> being able to check for space ahead of time, which is problematic (though maybe
> put could be changed to return whether it succeeded in order to deal with the
> case where you might be able to put more than it could fit and can't check
> first).

There are simpler fail cases than that, since an output range can accept ranges
of elements itself. Meaning you can do:
int[] a = [0, 0];
a.put([1, 2, 3]);

So as you did mention, basically, the problem is that even if the range is not
full, that doesn't guarantee that what you want to cram into it will fit.

I think going the *sformat* road might be simplest? It is *strongly*
recommended to use an infinite sink when an output range is passed. You are
free to use some sort of finite storage, but if it empties out, then it's
error.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------