Add data type guards #513
Add data type guards #513
Conversation
There was a problem hiding this comment.
In the documentation, I see @racket appear where @racketid might make more sense. That is, on identifiers assumed to be bound to no particular value for discussion purposes.
This is off topic for the PR, but you might introduce their use within your side of the diff in the manual. Either that or just open a different PR dedicated to the purpose.
| sorted alphabetically by field name, and the values it returns will be the | ||
| values stored in the record. | ||
|
|
||
| By default, record types are |
There was a problem hiding this comment.
This might just be an artifact of a rewrap, but this line seems to end too soon.
| created with properties that make them print like transparent structures, | ||
| except field names are included --- see @racket[default-record-properties] for | ||
| details.} | ||
|
|
||
| @defform[(record-guard-maker/c keyword-contract-pair ...) | ||
|
|
There was a problem hiding this comment.
Not unintentional but maybe unnecessary.
|
I think all of the |
|
Just stumbled onto this and just wandering what the status is? It would be a nice feature to have. |
Adds
#:guard-makerarguments for tuple, wrapper and record types, as well as<type>-guard-maker/cmacros for creating these from contracts.Since these are all implemented in terms of just the tuple type and its guard implementation, and is also somewhat repetitive, I believe it makes most sense to have all of these in a single PR.
Implements #42, and its subtasks: #202, #203, #204.
Supercedes #512. and the same caveat applies for the
<type>-guard-maker/cmacros: they may not be the best for applying contracts, since the calling party is not known to the guard procedure, and thus it has to take any blame for contract violations itself.