On Thu, May 08, 2014 at 11:27:54AM -0700, Walter Bright via Digitalmars-d wrote:
> On 5/8/2014 10:46 AM, Andrei Alexandrescu wrote:
> >A discussion is building around
> >https://github.com/D-Programming-Language/phobos/pull/2149, which is a nice
> >initiative by Walter to allow Phobos users to avoid or control memory
> >allocation.
>
> The setExtension() function is itself not very important, but what is
> important is an example for how to put together ranges.
>
> Some design goals:
>
> 1. purity, @safe, nothrow, @nogc
> 2. composability
> 3. have them work in a consistent way, so there's less for a user to learn
I think having setExtension() return an input range is the best
solution. It will satisfy all 3 requirements: it's easy to make it pure,
safe, nothrow, nogc (since it lazily generates the result); it's easy to
compose with UFCS chains, and it's consistent with the rest of the
range-based functions in Phobos.
Having setExtension (or any string function) take an output range would
break (2) -- you have to allocate intermediate buffers to serve as
output ranges if you want to do further processing of the result.
If setExtension returns an input range, then you can just use
std.algorithm.copy to copy the result to an output range should you need
to. Going the other way, you can't easily convert an output range into
an input range.
There is the issue of decoding, though. Perhaps setExtension should take
a compile-time argument specifying which char type is desired in the
result? So you could do:
string filename, ext;
wstring pathname_w = filename.setExtension!wchar(ext).array;
dstring pathname_d = filename.setExtension!dchar(ext).array;
This way, if the output char type is identical to the input char
type, the function can bypass decoding.
T
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask
about Exchange Server next. -- (Stolen from the net)
