A few holes (imho) in the ecosystem of libraries

[Andrew]

On Monday, 15 May 2023 at 14:23:24 UTC, Guillaume Piolat wrote:
> - if you reserve common works like `read`/`write` as identifier 
> for your library, it **will** be annoying downstream because it 
> clashes with other careless namespace landgrab from Phobos. 
> Like std.file.read, std.file.write std.stdio.read, 
> std.stdio.write. This is what happens in practice, and the 
> simple fact you use very common words for not-trivial operation 
> is a big deterrent. I had endless problems with Phobos min/max, 
> and ended avoiding those functions altogether. And "read" or 
> "write" do not say at all what your function does! This kind of 
> naming end up worse than C library names with prefixes.
> Also templated libraries often have lack of separation between 
> API and internals, this is poison to versionning.

Okay, this is good information to work with. It might make more 
sense to work under a `readFromStream` and `writeToStream` 
function name instead of generic `read` and `write`. If only D's 
module system could resolve such naming issues for us... Also, 
could you explain a little bit more about what you mean by "lack 
of separation between API and internals"? Do you mean exposing 
structs that should be defined inline or privately in the module?

And in your other reply you mentioned:

> you propose the fread interface (return numbner of read 
> elements), I've tried that in the image library and it's not as 
> nice as just returning a default value, such as zero on 
> failure, and fail out of band.

and this is definitely something I'll add; thanks for suggesting 
it.