Add provided methods Seek::{stream_len, stream_position} by LukasKalbertodt · Pull Request #58422 · rust-lang/rust (original) (raw)

I think that rules out position.

Is that really the case, though? RFC 1105 defines what changes are considered "major" and which ones are considered "minor". It says:

Minor change: adding a defaulted item

Adding a defaulted item is technically a breaking change: [...] According to the basic principles of this RFC, such a change is minor: it is always possible to annotate the call [...].

The RFC uses a different example to show that adding a defaulted item can be a breaking change, but I guess the reasoning still applies.

Now of course we wouldn't want to have a change that we know causes real breakage in the world -- regardless if it's minor or major according to the RFC. So I guess what I'm asking is: do you consider this one breakage in the compiler suite as enough evidence that such a change is not OK? Or would it be better to have a crater run?

As @jonas-schievink pointed out in a private chat with me, the code that breaks in Travis is extremely fishy: neither get_ref nor position of Cursor need a mutable reference, so ref cursor should be enough. Furthermore the mutable reference is then explicitly dropped which shouldn't do anything because it's at the end of its scope anyway. That doesn't mean that there can't be non-fishy code that breaks under this change to Seek, but I guess it's still worth mentioning that in that particular case, everything would be fine if the code was "more correct".

but not to position which only changes if we act on the stream from the current thread of execution.

That's not necessarily true, right? Someone could implement Seek for a type that can be shared across multiple threads. (Although I still agree that current_ in current_position is kinda bad.)

I don't like the io_ prefix. I would be fine with stream_len and stream_position (although I'm not super happy about the stream_position). Alternatives: seek_position or position_in_stream?