On Tuesday, 26 January 2016 at 06:27:49 UTC, H. S. Teoh wrote:
On Sun, Jan 24, 2016 at 06:07:41AM +0000, Jesse Phillips via
Digitalmars-d-learn wrote: [...]
My suggestion is to take the unittests used in std.csv and try
to get your code working with them. As fastcsv limitations
would prevent replacing the std.csv implementation the API may
not need to match, but keeping close to the same would be best.
My thought is to integrate the fastcsv code into std.csv, such
that the current std.csv code will serve as fallback in the
cases where fastcsv's limitations would prevent it from being
used, with fastcsv being chosen where possible.
That is why I suggested starting with the unittests. I don't
expect the implementations to share much code, std.csv is written
to only use front, popFront, and empty. Most of the work is done
in csvNextToken so it might be able to take advantage of
random-access ranges for more performance. I just think the
unittests will help to define where switching algorthims will be
required since they exercise a good portion of the API.
