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
