Jacqueline Firth

I don't think it's possible, nor do I think it's something we want to encourage in the first place. What were you planning to use this functionality for?

I don't think you need `require/expose` for that. You can use `dynamic-rerequire` instead, possibly combined with `all-defined-out`. You might also be interested in [`racket-reloadable`](https://github.com/tonyg/racket-reloadable-example), which uses `dynamic-rerequire` to implement hot...

> Sounds like a good idea but check-equal? outside of test-case should stay the same. Please. Why? Not against the idea, just wondering if there's a specific problem you have...

> I would feel less surprised if the API has a new name, perhaps with syntax > > ```racket > (check-app/infer-name f x1 x2 ... xn ) > ``` >...

> Just curious, doesn't your `expect` support something more powerful? It does, but after using `expect` for a while I gave up and went back to vanilla rackunit. It turns...

> I am just asking for backwards compatibility, the usual Racket guideline. So ``` (module+ test (check-equal? (f 1 2 3) 4) ) ``` should not change functional behavior though...

> Sure. My point is not against adding inferred information, but such inference should be uniform. In the best scenario, there should be no extra rules to demand the user...

@samdphillips That looks about right, although I actually recommend against adding info for expressions in the "expected" position. Focusing on the "actual" position seems like a better approach since the...

Realistically we can't change `test-suite` to be an alias of `test-case` because of backwards compatibility. Honestly my take is that test suites were a mistake and shouldn't have existed. My...

Symmetry with the output of checks, since check failures print `"FAILURE"` while check errors print `"ERROR"`. If you have a suggestion for a less ambiguous name, I'm all ears.