You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Part of #42. Wrapper types should allow guards. The signature of a wrapper guard should match the contract (-> wrapper-type? any/c any/c), accepting an argument with information about the wrapper type (in order to use the type name in error messages, for instance) and an argument for the value being wrapped. It should return a single value representing the replacement value to wrap (possibly normalized to some canonical form, or wrapped with a chaperone, etc.).
Then, the make-wrapper-implementation function and the define-wrapper-type macro should both accept an optional #:guard parameter matching this contract. As a convenience, a (wrapper-guard/c contract) contract combinator should construct a function suitable for use with the #:guard option that simply checks the field with the contract.
Wrapper type guards can possibly be implemented more efficiently than tuple type guards (see #203), since they can assume exactly one field and there's no need to call apply anywhere in the code that translates tuple guards to struct guards.
The text was updated successfully, but these errors were encountered:
Update: guard functions should probably match the contract (-> wrapper-type? (-> any/c any/c)), just to get any allocation related to error messages out of the way at type creation time.
Part of #42. Wrapper types should allow guards. The signature of a wrapper guard should match the contract
(-> wrapper-type? any/c any/c)
, accepting an argument with information about the wrapper type (in order to use the type name in error messages, for instance) and an argument for the value being wrapped. It should return a single value representing the replacement value to wrap (possibly normalized to some canonical form, or wrapped with a chaperone, etc.).Then, the
make-wrapper-implementation
function and thedefine-wrapper-type
macro should both accept an optional#:guard
parameter matching this contract. As a convenience, a(wrapper-guard/c contract)
contract combinator should construct a function suitable for use with the#:guard
option that simply checks the field with the contract.Wrapper type guards can possibly be implemented more efficiently than tuple type guards (see #203), since they can assume exactly one field and there's no need to call
apply
anywhere in the code that translates tuple guards to struct guards.The text was updated successfully, but these errors were encountered: