On Friday, 31 March 2023 at 02:23:29 UTC, Steven Schveighoffer
wrote:
There's a certain attempt in phobos in some places to try and
ensure code that is going to confuse will not compile. I think
this is one of those attempts.
Consider that if you pass a slice into `put`, then it returns
nothing. There is no indication of what actually was written.
It's essentially an inconclusive call, because the "result" is
the output range itself. How many elements were written? You
can't tell.
This is a general issue with the `put` interface—it has no
standardized way to report failure or partial success to the
caller. And the problem applies to both lvalue and rvalue output
ranges. For example:
```d
void main()
{
import std.stdio, std.range;
auto sink = stdout.lockingTextWriter;
put(sink, "hello");
}
```
How many characters were written? Nobody knows! Maybe you can
find out with `File.tell`, if the file is seekable, but there's
no guarantee it is. And if you're working in a generic context,
where you don't know the specific type of output range you're
dealing with? Forget it.
I'd argue that the way input ranges are used as output ranges
today is extremely confusing. It makes sort of a logical sense,
but the fact that you need to store your "original" range, and
then do some length math to figure out what was written makes
such code very awkward all around. The output is decipherable,
but not obvious.
I stand by my assertion that probably lvalue input ranges
should never have been treated as output ranges implicitly.
They should have had to go through some sort of wrapper.
IMO this is downstream of the issue with `put`. If `put` itself
returned information about what was written, then there would be
no need to try and recreate that information via side channels
like this (or like `File.tell`).
I agree that there are ways we could change things to make the
side channels easier to use, but ultimately that's treating the
symptom, not the disease.
