Skip to content

Add get-failure-result to racket/function #4854

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

lexi-lambda
Copy link
Member

This adds a very simple function named get-failure-result to racket/function. It is essentially just

(define (get-failure-result v)
  (if (procedure? v) (v) v))

except that the version in this PR also includes an explicit arity check.

Since this function is so simple, the convenience it affords is obviously extremely minor. Still, I’ve written it so many times that it feels worth putting somewhere, especially since we already have failure-result/c.

@sorawee sorawee added the api design Related to the design of core libraries and language features label Dec 7, 2023
@sorawee sorawee added this to the 8.12 milestone Dec 9, 2023
(if (procedure-arity-includes? v 0)
(v)
(raise-argument-error 'get-failure-result
"a procedure that accepts 0 non-keyword arguments"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should use (procedure-arity-includes/c 0) as the contract string, I think.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The intent here may have been to match the exception raised by hash-ref. It needs to different, though, to do that. The hash-ref function conceptually always applies a procedure failure result to 0 arguments, but it improves the exn:fail:contract:arity error message.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The error message is based on the one produced by failure-result/c, which is really just the error message produced by (-> any). I’m happy to change it, if desired, but consistency with failure-result/c seemed logical.

@sorawee sorawee modified the milestones: 8.12, 8.13 Jan 7, 2024
@LiberalArtist
Copy link
Contributor

the version in this PR also includes an explicit arity check

I have also written this function multiple times, but I think I have rarely if ever implemented an explicit arity check. That seems quite useful for cases when the argument isn't already protected by failure-result/c. It might be worth adding an optional #:who argument for even better error reporting in such cases.

@shhyou shhyou removed this from the 8.13 milestone Apr 24, 2024
@shhyou shhyou added the pr:needs-work A PR that's wanted but needs work to be mergeable. label Apr 24, 2024
@lexi-lambda lexi-lambda removed the pr:needs-work A PR that's wanted but needs work to be mergeable. label Oct 20, 2024
@lexi-lambda lexi-lambda requested a review from mflatt October 20, 2024 06:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api design Related to the design of core libraries and language features
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants