What I suggested in my original post didn't involve any indirection/abstraction; simply a renaming to be consistent with existing zlib (see my points A+B in my 1st post on this thread):

std.compress.zlib.compress
std.compress.zlib.uncompress
std.compress.lzw.compress
std.compress.lzw.uncompress

same reason we have: std.file.write, std.stdio.write, etc, and not std.fileWrite, std.stdioWrite.

On Tue, Jun 4, 2013 at 11:18 PM, Walter Bright <newshound2@digitalmars.com> wrote:
On 6/4/2013 9:44 PM, Max Samukha wrote:
On Tuesday, 4 June 2013 at 18:46:49 UTC, Walter Bright wrote:
On 6/4/2013 11:43 AM, Timothee Cour wrote:
writing generic code.
same reason as why we prefer:
auto y=to!double(x) over auto y=to_double(x);

The situations aren't comparable. The to!double case is parameterizing with a
type, the compress one is not. Secondly, compress(lzw) does ABSOLUTELY NOTHING
but turn around and call lzw. It adds nothing.

That "absolutely" based on limited personal experience is the biggest D's problem.

I've seen an awful lot of abstractions over the years that provided zero value.

You need to provide a compelling use case to justify another layer of complexity. "generic code" is not a compelling use case. It's already generic.

Note how these components are to be used:

    src.lzwCompress.copy(dst);

Your proposal is:

    src.compress(lzw).copy(dst);

I.e. zero value, as so far all compress() does is call lzw().

The whole point of range-based pipeline programming is you can just plug in different components. There is no demonstrated use case for adding another layer.

I am actually wrong in saying it has zero value. It has negative value :-)