`<FutureReader<T> as IntoFuture>::Output` should be `Result<T, ErrorContext>`

[dicej]

Currently, <FutureReader<T> as IntoFuture>::Output is Option<Result<T, ErrorContext>>, but that's due to my earlier, incorrect understanding of the spec. The spec says the owner of the write end of the future must either write a value before closing it or close it with an error, so the only two possible outcomes for the read end are a value or an error. And note that if the writer writes a value and then closes it with an error, the error will be silently dropped, just like it would be if the reader had already explicitly closed its end.

[alexcrichton]

The spec says the owner of the write end of the future must either write a value before closing it or close it with an error

If this is true this is worrisome to me since I think it should always be possible to close a resource at any time as part of normal cleanup. Reading over the spec currently though I have a different takeaway than you where close can happen at any time with an optional error-context (which is what I'd expect)

Am I missing other portions of the spec though? Or maybe a contradicting spec? Or I'm misunderstanding the pseudocode...

[dicej]

The spec says the owner of the write end of the future must either write a value before closing it or close it with an error

If this is true this is worrisome to me since I think it should always be possible to close a resource at any time as part of normal cleanup. Reading over the spec currently though I have a different takeaway than you where close can happen at any time with an optional error-context (which is what I'd expect)

Am I missing other portions of the spec though? Or maybe a contradicting spec? Or I'm misunderstanding the pseudocode...

Yeah, I found it confusing, too. From the explainer:

A future is a special case of stream and (in non-error scenarios) delivers exactly one value before being automatically closed.

Also @lukewagner mentioned that there is something in the Python code to enforce this, but I don't know where it is offhand.

[lukewagner]

The trap (if closing when no value had been written but without an error-context) is at the end of this section.

Note that you can always error.context.new from nothing, so if you are in the middle of nowhere and need to future.close-writable, you can always error-context.new right there.