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:
import std.stdio, std.range;
auto sink = stdout.lockingTextWriter;
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 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
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.