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".
possibly introduced in https://github.com/dlang/phobos/pull/5229
`ElementType!(typeof(chain(s, "\n")))` returns `uint`. That's the problem. Now, why ElementType should return `uint` is a different story... gonna investigate now.
(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
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.
@SSoulaimane updated dlang/dmd pull request #9889 "Fix issues 17141, 17358 - Ternary operator converts characters to integers" fixing this issue: - Fix issues 17141, 17358 - Ternary operator converts characters to integers https://github.com/dlang/dmd/pull/9889
dlang/dmd pull request #9889 "Fix issues 17141, 17358 - Ternary operator converts characters to integers" was merged into master: - 8826be69875448bfb18ecb887e89567e75a1b48f by سليمان السهمي (Suleyman Sahmi): Fix issues 17141, 17358 - Ternary operator converts characters to integers https://github.com/dlang/dmd/pull/9889