This compiled in 2.073.2 and doesn't anymore
void main()
{
import std.stdio;
import std.range;
import std.conv;
auto f = File("test", "w");
auto s = 42.toChars;
f.lockingTextWriter.put(chain(s, "\n"));
}
test2.d(12): Error: template std.stdio.File.LockingTextWriter.put cannot deduce function from argument types !()(Result), candidates are:
/usr/local/Cellar/dmd/2.074.0/include/dlang/dmd/std/stdio.d(2742): std.stdio.File.LockingTextWriter.put(A)(A writeme) if ((isSomeChar!(Unqual!(ElementType!A)) || is(ElementType!A : const(ubyte))) && isInputRange!A && !isInfinite!A)
/usr/local/Cellar/dmd/2.074.0/include/dlang/dmd/std/stdio.d(2773): std.stdio.File.LockingTextWriter.put(C)(C c) if (isSomeChar!C || is(C : const(ubyte)))
To be honest, I have no idea what is going on here, because the sig constraint
pragma(msg, (isSomeChar!(Unqual!(ElementType!A)) || is(ElementType!A : const(ubyte))) && isInputRange!A && !isInfinite!A);
prints "true".
`ElementType!(typeof(chain(s, "\n")))` returns `uint`. That's the problem. Now, why ElementType should return `uint` is a different story... gonna investigate now.
Comment #3 by jack — 2017-04-28T18:35:35Z
(In reply to hsteoh from comment #2)
> `ElementType!(typeof(chain(s, "\n")))` returns `uint`. That's the problem.
> Now, why ElementType should return `uint` is a different story... gonna
> investigate now.
https://issues.dlang.org/show_bug.cgi?id=17141
Comment #4 by schveiguy — 2017-04-30T20:27:52Z
Yes, the bug that the PR fixed was to prevent lockingTextWriter.put from taking an arbitrary byte, ubyte, short, ushort, int, or uint range and integer promoting the elements to dchar. It was decided to allow ubyte[] specifically (and write it directly as an array of ubytes), because of the inability to use byChunk and lockingBinaryWriter to achieve a direct copy of a file.
IMO, the whole system is really messed up. It doesn't make sense to accept a range of arbitrary bytes to a text writer, but lockingBinaryWriter changes the stream from a text to binary (Which means something for Windows newlines).
I'm not sure of a "correct" way to fix this regression (which really is erroneous behavior which happened not to blow up). If the identified CommonType bug is fixed, we still are dealing with integer promoting chars to dchars inside chain, which isn't right either.