• Jesse Phillips (37/40) Mar 19 2015 Over in this big long thread:

"Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:

Over in this big long thread: 
http://forum.dlang.org/post/otbosnagosqpvmskirtw forum.dlang.org

There is mention of being able to store the csvReader struct:

On Tuesday, 17 March 2015 at 10:31:06 UTC, Almighty Bob wrote:
 It's far more useful for csvReader to return a type I know and
 can use than it is to obscure the return type for the sake of
 some philosophical ideal of increasing encapsulation.

So the question is, is this something people would really want?

Here is the signature for the struct return:

     private struct CsvReader(Contents, Malformed ErrorLevel, 
Range, Separator, Header);

This could be made public, and assuming you're not processing 
text after a map!() or filter!() this struct would have 
declarations like:

     CsvReader!(string, Malformed.throwException, string, dchar, 
string[]) foo;

vs today:

     typeof(csvReader("")) foo;

Because it is private it also doesn't show up in the 
documentation, maybe making it public would help to improve 
documentation?

CsvReader also returns another internal range:

     private struct CsvRecord(Contents, Malformed ErrorLevel, 
Range, Separator);

This would be much harder to specify as a return type, because 
CsvRecord is conditioned for three situations (struct/class, 
hashtable, generic). I'm pretty sure to specify CsvReader.front's 
return type I would need 3 different CsvReaders, which would mean 
3 different csvReader helper functions, so we would see an API 
change to:

     CsvReaderStructured!(Contents, Malformed ErrorLevel, Range, 
Separator, Header) csvReaderStructured!()()
     CsvReaderHashTable!(Contents, Malformed ErrorLevel, Range, 
Separator, Header) csvReaderHashTable()
     CsvReaderDataOnly!(Contents, Malformed ErrorLevel, Range, 
Separator, Header) csvReaderDataOnly!()()

This wouldn't need to be a breaking change as all the logic could 
still be placed into the original 'auto csvReader()' function.

To Almighty's point, philosophical encapsulation has little to do 
with the design, instead it was chosen to simplify the API.