Std::io::seek

[Xpyder]

std::io::seek

A seek beyond the end of a stream is allowed, but implementation defined.

should probably be

A seek beyond the end of a stream is allowed, but behavior is undefined.

Not sure if this is where I’m supposed to post this, but it’s the closest I’m currently aware of

[cuviper]

You could submit such a change as a pull request on https://github.com/rust-lang/rust/.

However, the usual meaning of undefined behavior does not apply to this case. UB is unsafe and should be avoided altogether, whereas implementation-defined behavior just means that some systems will handle this differently than others.

[Xpyder]

oh, so “implementation defined” is known specific terminology? I thought it was a grammatical mistake

[cuviper]

Yes, it’s an industry term – here’s implementation-defined behavior. These links mostly talk about C and C++, but Rust uses the same terminology, especially since LLVM is first and foremost a C and C++ backend.

If you think this could be confusing to unfamiliar users, it might be worth adding some clarification.

[gbutler]

No, “Implementation Defined Behavior” and “Undefined Behavior” are definitely different things and terms of art. “Implementation Defined” usually refers to something which will not be the same across implementations, but, that will have a definite, safe behavior on a given implementation, whereas, “Undefined Behavior” refers to something where even a specific implementation will not specifically define what will occur and, in fact, anything at all is free to occur, hence making it unsafe.

[Xpyder]

Yes, it’s an industry term – here’s implementation-defined behavior […] If you think this could be confusing to unfamiliar users, it might be worth adding some clarification.

I didn’t realize, maybe something like this then?

A seek beyond the end of a stream is allowed, but it is implementation-defined.

the hyphen makes it clear “implementation defined” is a known concept (and matches it’s usage elsewhere) and the “it is” makes it a bit more clear that the full sentence is considered and intentional.

While normally I find brevity improves clarity, in this case if you don’t realize “implementation defined” is a single concept, it sounds like a thought that trailed off after an edit

[steveklabnik]

I’d take a PR for that.

[dcarosone]

A seek beyond the end of a stream is allowed, but the effect is implementation-defined.

FSVO of “effect” that might be “behaviour”, “result”, or suitable synonym.

[Centril]

I would clarify this as:

A seek beyond the end of a stream is allowed, but is defined by each implementation of the Seek trait.

which is more unambiguous.

[glandium]

I would clarify this as:

A seek beyond the end of a stream is allowed, but is defined by each implementation of the Seek trait.

which is more unambiguous.

OTOH, the implementations docs are a) hidden by default b) don’t say what the implemented behavior is. Funnily enough, it’s likely that for File, the behavior is implementation-defined at the OS level.

[Xpyder]

I’m a bit out of practice on doing PRs so I opened it as an issue over on Github.

[Ixrec]

With terms of art like “undefined behavior” and “implementation defined” that we really have to use in documentation, yet not everyone is aware they have a very specific well-known definition, I think the only complete solution would be to make all uses of them in official documentation links to a standard glossary or FAQ entry or something.

[Xpyder]

… would be to make all uses of them in official documentation links to a standard glossary or FAQ entry

That’s not a bad idea for the larger picture.

I think in this case the hyphen and additional wording are enough to make it clear it’s a considered sentence and not leftovers from a previous edit

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.