Can't call splitter with range struct

[David Skluzacek]

I came across this problem as I was trying to see if could write 
a quick range-based solution with std.zlib to do what was asked 
about in a different Learn forum post - read a gzipped file.

This seems like it should work:

import std.stdio, std.algorithm, std.zlib;
import std.range.primitives;

void main(string[] args)
{
     auto f = GZippedFile(File(args[1], "rb"));
     f.splitter("\n").each!writeln;
}

struct GZippedFile
{
     File file;
     UnCompress uncompressor;
     ubyte[] readBuffer;
     const(char)[] buffer;

     this(File f) {
         file = f;
         uncompressor = new UnCompress(HeaderFormat.gzip);
         readBuffer = new ubyte[4096];
     }

     dchar front() const {
         return buffer.front;
     }

     void popFront() {
         if (buffer.empty) {
             buffer = cast(const(char)[])
                 uncompressor.uncompress(file.rawRead(readBuffer));
         }
         else {
             buffer.popFront();
         }
     }

     bool empty() {
         return buffer.empty && file.eof();
     }
}

But I get:

Error: template std.algorithm.iteration.splitter cannot deduce 
function from argument types !()(GZippedFile, string), candidates 
are:
/usr/include/dlang/dmd/std/algorithm/iteration.d(4678):        
splitter(alias pred = "a == b", Range, Separator)(Range r, 
Separator s)
   with pred = "a == b",
        Range = GZippedFile,
        Separator = string
   must satisfy the following constraint:
        is(typeof(binaryFun!pred(r.front, s)) : bool)
(...)

If I change the newline separator to a character literal, I get:

(...)
/usr/include/dlang/dmd/std/algorithm/iteration.d(5055):        
splitter(alias pred = "a == b", Range, Separator)(Range r, 
Separator s)
   with pred = "a == b",
        Range = GZippedFile,
        Separator = char
   must satisfy the following constraint:
        is(typeof(binaryFun!pred(r.front, s.front)) : bool)

It seems like "\n" should pass the second constraint and '\n' 
should pass the first.  Using a dchar or dstring makes no 
difference. Adding @property to front makes no difference. Is 
this a bug?