Tracking issue for RFC 2011: Generic assert

[alexcrichton]

This is a tracking issue for rust-lang/rfcs#2011.
The feature gate for the issue is #![feature(generic_assert)].

Sub tracking-issue: #96949.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Implementation (see section Implementation history)
• Final comment period (FCP)¹
• Stabilization PR

Blockers

• Does not work in const eval yet.

Implementation history

• [RFC 2011] Library code #97233
• [RFC 2011] Basic compiler infrastructure #97450
• [RFC 2011] Minimal initial implementation #97665
• [RFC 2011] Expand expressions where possible #98148
• [RFC 2011] Optimize non-consuming operators #98337
• [RFC-2011] Expand more expressions #111928
• [generic_assert] Constify methods used by the formatting system #135139
• [generic_assert] "Constify" the Debug trait #135712

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[bstrie]

@alexcrichton The last time that you and I discussed this (in March 2013: #5436 (comment)) you noted that assert_eq has different and potentially unexpected semantics compared to straight assert, in that assert_eq checks for equality commutatively, whereas assert does not.

If this RFC were to be implemented, we would either need to decide whether to make assert!(foo == bar) also assert when bar == foo, which is technically a breaking change. The alternative is to leave the behavior of assert!(foo == bar) as-is, but then it no longer has the exact same semantics as assert_eq, which the RFC intends to deprecate. I think this is a pretty important unanswered question.

Is the idea that nobody needs the commutative equality, so we should just deprecate assert_eq without duplicating its semantics?

[durka]

@bstrie your concern was obsoleted in 2015 :)

[bstrie]

Glad to hear it. :)

[emilio]

Quick question, is it expected for this to have some sort of switch to less-nice error messages? Sometimes people care about code size, and including a bunch of debug formatters on release builds may not be acceptable.

[ishitatsuyuki]

This was one of the concerns in the RFC, and following are some points:

• The performance impact may be minimal, as the first step is just making assert having assert_eq's functionality.
• If notable regression was found, we may decide to disable some of the rules for release builds.
• For certain critical path, debug assertions or custom formatters may be used to minimize (control) the performance impact, just as before.

[sinkuu]

I am trying to implement this, but have not been successful so far. The problem is that we don't know if a operand is Copy during macro expansion.

Status quo(sinkuu@ba00a0e):

assert!(a == b && c)

expands to

let mut __capture0 = None;
let mut __capture1 = None;
let mut __capture2 = None;
// `try_copy` copies it if it implements `Copy`
if !({ let __tmp = a; __capture0 = __tmp.try_copy(); __tmp }
   == { let __tmp = b; __capture1 = __tmp.try_copy(); __tmp }
   && { let __tmp = c; __capture2 = __tmp.try_copy(); __tmp }) {
    panic!("assertion failed: a == b && c\nwith expansion: {:?} == {:?} && {:?}", ...);
}

But this moves non-Copy operands into assert, and causes use-after-move afterward.

@ishitatsuyuki Do you have concrete implementation strategies in mind?

[ishitatsuyuki]

@sinkuu Nice work! However, PartialEq takes self by reference, which means you don't have to copy/clone it. In this case, we may have to call the trait methods directly instead of the operators.

In the case of moving Ops like Add, your approach is good and should just work.

Another thing is that we should use our own enum instead of Option here, as we need to handle the case of non-Copy type and the case of short-circuit differently.

[shepmaster]

You might be able to use the tricks that assert_eq! uses to take references to the arguments as well.