std.csv accepted into Phobos

Jonathan M Davis jmdavisProg at gmx.com
Sun Nov 20 15:06:31 PST 2011


On Sunday, November 20, 2011 20:38:13 Jesse Phillips wrote:
> On Sun, 20 Nov 2011 09:07:17 -0500, dsimcha wrote:
> > I'm pleased to announce that, by a vote of 5-1, std.csv has been
> > accepted into Phobos.  Also, by a vote of 3-2 with one abstention, the
> > community has decided on Version 2 of the library (the one where the
> > Record struct, etc. is hidden in a style similar to std.algorithm rather
> > than explicitly documented).  Congratulations, Jesse.
> 
> Thank you, and maybe since I'm sure few people were voting specifically
> for how the Exceptions were organized, Nick's suggestion could be added?

Personally, I would have no problem with you adjusting the exceptions so that 
they were derived from CSVException (possibly changing the current 
CSVException to a new exception and creating a new CSVException which is the 
base type of them all if that makes more sense given the issue with row and 
col). That's a fairly minor part of the API, and in general, I think that it's 
a good idea that exceptions in a module be derived from an exception type 
named after that module if there's more than one exception type in the module, 
since most of the modules in Phobos have an exception type named after 
themselves. So, it increases consisntency and makes it easy to specifically 
catch all exceptions that a particular module throws.

> One thing to note about the docs is that, if we do get a lot of questions
> around the returned type, it can be expanded again (were as removing
> documentation is just strange).

Yeah. Though as i pointed out in another post, it seems to me that the real 
issue is that you're essentially dealing with a completely different return 
type from csvReader based on the Contents type that you give it, which would 
make it desirable to document the two situations as separate functions, but 
the fact that it's the template argument which does it (causing template 
constraints and/or static if to make them different) makes it so that you don't 
actually have two separate signatures to document.

Regardless, documentation can be adjusted (including moving the struct out of 
csvReader if we want to later), but moving a separate struct into a a function 
later breaks code, so making that decision only to decide later that it was a 
bad idea is far more limiting than hiding it first and then changing our minds 
later.

- Jonathan M Davis


More information about the Digitalmars-d mailing list