Add "Logic errors" as behavior not considered unsafe

[ojeda]

In rust-lang/rust#80657 and rust-lang/rust#80681 it is discussed how to clarify/define what a "logic error" is and what are their consequences. The reference should mention them as well.

We could use other term instead of "unspecified", e.g. "unpredictable"; in case we want to emphasize that the results may not the same between runs, builds, kinds of build, etc. For instance, from the description of integer overflow, it looks like the implementation needs to choose some reasonable behavior (e.g. a panic or wrap around), even if not documented (therefore, "unspecified", in terms of the C and C++ standards). However, logic errors seem to require more freedom: the implementation may not even be able (or want) to predict what may happen, so it cannot "reasonably choose" a particular behavior, even if such behavior is guaranteed to be safe (similar to deadlocks, although in that case the set of possible behavior is known, even if nondeterministic between runs).

As I mentioned in one of the linked discussions, it might be a good idea to define a separate, clear term for this kind of behavior that is considered erroneous and unpredictable, yet safe. So not exactly "unspecified", at least as used in the C and C++ standards -- it is closer to "safe UB" than "unspecified". In other words, in the same spirit as C's "bounded UB" or Ada's "bounded error". Ideally, the term would not overload another common term in other language specs (like UB).

[Havvy]

Mostly little wording changes.

Can you also point to the Hash+Eq contract defined by Hash? https://doc.rust-lang.org/std/hash/trait.Hash.html#hash-and-eq ; That way it's not just data structures that shown, but also that trait invariants can be broken in safe code. This is important because it means that unsafe code can't rely on invariants defined by safe traits.

[ojeda]

This is important because it means that unsafe code can't rely on invariants defined by safe traits.

Indeed, which is one reason it would be great to actually list all the "logic errors" instances in core etc. somewhere; similar to the UB and unspecified lists in the C standard. Or at least always use a term ("logic error" or something else; or have a section of "Constraints" like the "Panics" one) so that it can be greppable/shown distinctively (e.g. currently the Hash+Eq doesn't).

(I haven't spelled this point out since it was an example, but I can split the two examples into two paragraphs and give more detail to this one if you prefer).

[Havvy]

I forgot to mention, please don't force push after a review. It makes it impossible to see what has changed from push to push.

[Havvy]

cc @RalfJung ; does this look alright?

[ojeda]

I forgot to mention, please don't force push after a review. It makes it impossible to see what has changed from push to push.

Yeah... GitHub should really fix that.

Thanks for the review and your patience with my English!

[RalfJung]

Hm... yes the text makes sense, but I am not sure about the best place for putting it. Currently we probably don't have a better place than this though.

This touches on the larger story of "language UB" vs "library UB" -- there's assumptions the compiler makes about what the code does (and violating them is language UB), and there are assumptions that libraries make about what their callers do (and violating them is library UB). The "list of UB" in the reference is certainly about language UB, these logic errors are a concept related to library APIs and thus more closely related to library UB. Related to this is also the distinction of validity invariants vs safety invariants, which one could call "language invariants" and "library invariants", respectively.

My concern with this change is that it might lead to even more confusion between language UB and library UB. But maybe this is still okay for now. Longer-term, the reference should more clearly tease apart these two concepts.

[Mark-Simulacrum]

It might make sense to try and put this in the API guidelines, which is closer to library and generally feels better than documenting non-language concerns in the reference.

[Havvy]

API guidelines sounds like a good place to me. This chapter is entirely about things that don't actually concern the language, so it doesn't technically fit the reference, but it's a good chapter to have in juxtaposition of the chapter that says what is, so I'm fine with having it here nonetheless.

[RalfJung]

This chapter is entirely about things that don't actually concern the language, so it doesn't technically fit the reference, but it's a good chapter to have in juxtaposition of the chapter that says what is, so I'm fine with having it here nonetheless.

I think it'd be better to have a proper introduction of language UB vs library UB. But this is probably a longer-term project which also involves adjusting the stdlib documentation to better distinguish these two kinds of UB.

[Mark-Simulacrum]

Yes, I agree that having the distinction between the kinds of UB in the reference makes sense. I think the impacts of that on libraries (e.g. this notion of logic error / safe but unspecified behavior) might be better suited for API guidelines or similar places.

[ojeda]

What is considered library? Is it always a clear cut? For instance, I guess one could argue the Hash and Eq example to be part of the language itself (and not just the library) since it involves a built-in operator trait. In such case, one could argue it is "language UB" (but safe, in this case).

Similarly, in C one could argue stddef.h is part of the "core" language since it is one of the headers that are always present, even in freestanding implementations (plus a "language" operator like sizeof or pointer subtraction return values of type size_t or ptrdiff_t respectively, which are introduced by that header, etc. etc.).

So I definitely agree it is a good idea to define these differences between kinds of UB in the reference somewhere. Perhaps the page introducing that could be the parent of the two "Behavior ..." ones.

[Havvy]

@ojeda The language aspect is that x == y desugars to an Eq::eq method call, but the library semantics are what Eq::eq() is supposed to mean. The language does not care at that is means equality. This is very clear cut.

@RalfJung Language UB vs Library UB should definitely be documented in the Behavior Considered Unsafe chapter. That said, I think it's orthogonal to logic errors not being UB and that might be surprising, so specifically stating it is important.

[ojeda]

@Havvy I am not talking about what equality means, but about the constraint itself. The constraint may be spelled out in a library file now; but it could very well be that it had been spelled out in the language itself. C++ also has its fair share of magic bits that blend the line between the library and the language; even if the standard delineates what is "library" and what is "language".

Anyway, my point is that I believe it is not that important whether some UB comes from the library or from the language -- defining clear terms and what kind of consequences each entails (bounded/safe UB? unbounded/unsafe UB? unspecified? ...) is more important; because those are then used to document things in code/libraries/etc. and in day-to-day conversation.

[RalfJung]

What is considered library? Is it always a clear cut?

Yes, I think it is fairly clear-cut: the language is everything that an interpreter like Miri needs to implement "by hand"; everything else is a library.

I am not talking about what equality means, but about the constraint itself. The constraint may be spelled out in a library file now; but it could very well be that it had been spelled out in the language itself.

Sure, but it wasn't. That's like saying "we are using fn as the keyword for functions but we could have used fun". It's true, but besides the point. When designing a language, there is some wiggle room for what to make a language primitive and what to leave to the library; but Rust made certain choices here and once that choice is made, for Rust, the answer is clear-cut.

Now, one could argue that we should permit other Rust implementations to make different choices here than rustc. Maybe this is what you mean. But I still think there is such a thing as "core Rust" that we can describe precisely and than contains all language UB, and we can define the API surface of libstd on top of that and add library UB where needed.

Anyway, for Eq and Hash, there is no UB, this this is certainly a library concept and not a language concept.

Language UB vs Library UB should definitely be documented in the Behavior Considered Unsafe chapter. That said, I think it's orthogonal to logic errors not being UB and that might be surprising, so specifically stating it is important.

I think it might be confusing because "logic error" is a library concept, which I feel like shouldn't occur on a page dedicated to language UB. But, as I already said, I have no better place to suggest either.

[ojeda]

Yes, I think it is fairly clear-cut: the language is everything that an interpreter like Miri needs to implement "by hand"; everything else is a library.

And a language can include such a constraint. In fact, one can argue we don't know if it does or doesn't, since the reference is non-normative and not complete (see below).

Sure, but it wasn't. That's like saying "we are using fn as the keyword for functions but we could have used fun". It's true, but besides the point. When designing a language, there is some wiggle room for what to make a language primitive and what to leave to the library; but Rust made certain choices here and once that choice is made, for Rust, the answer is clear-cut.

First of all, I was merely posing a question to try to understand the mind-frame of the writers of the reference, not arguing for or against it particular choices, precisely because I know there is this wiggle room.

Second, the reference is non-normative and, most importantly, a work in progress. So no, things are never set in stone -- not even in formally standardized documents that are supposed to be normative. Furthermore, it doesn't really matter that "Rust made certain choices" when discussing the changes to the reference itself: it is a cyclic argument.

Third, the key point here is where are these "certain choices" documented and how. In the introduction, the reference claims the "standard library" is not documented by it. Not only that is not clear-cut at all, it is not even defined what the "library" is supposed to be or include or not. One can claim it is "everything not in the reference", but that would require assuming the reference is complete, which it isn't (as it claims itself). One can also claim it is "everything documented in the library" too, but as said above, that requires clarification when written from the point of view of the reference.

Finally, if one wants to take away something from this, it should be "this probably needs to be clarified", not "you are making a pointless/vacuous argument"; which is non-constructive.

Now, one could argue that we should permit other Rust implementations to make different choices here than rustc. Maybe this is what you mean.

Well, one of the points of having a reference is to make it clear what and what cannot be done by implementations, definitely; but more importantly, and this is what I was referring about, is to define terms and vocabulary that everyone can refer back to. While instances of "library UB" may be defined in the library itself, the concept of "library UB" should be in the reference. That is to say: to define e.g. "language UB" and "library UB", one needs to know where the line between language and library is -- it does not particularly matter where it is in a given language, just that it is clearly defined what is what.

But I still think there is such a thing as "core Rust" that we can describe precisely and than contains all language UB, and we can define the API surface of libstd on top of that and add library UB where needed.

Agreed.