▼ |  | The Typed Racket Reference

1 | Type Reference
2 | Special Form Reference
3 | Libraries Provided With Typed Racket
4 | Typed Classes
5 | Typed Units
6 | Utilities
7 | Exploring Types
8 | Typed Racket Syntax Without Type Checking
9 | Typed Regions
10 | Optimization in Typed Racket
11 | Unsafe Typed Racket operations
12 | Legacy Forms
13 | Compatibility Languages
14 | Experimental Features

On this page:

unsafe-require/ typed
unsafe-provide
unsafe-require/ typed/ provide

7.2
top ← prev up next →

### 11`` Unsafe Typed Racket operations

(require typed/racket/unsafe) | package: typed-racket-lib

Warning: the operations documented in this section are unsafe, meaning that they can circumvent the invariants of the type system. Unless the #:no-optimize language option is used, this may result in unpredictable behavior and may even crash Typed Racket.

> > syntax

> > (unsafe-require/typed m rt-clause ...)

This form requires identifiers from the module m with the same import specifications as require/typed.

Unlike require/typed, this form is unsafe and will not generate contracts that correspond to the specified types to check that the values actually match their types.

Examples:

> > (require typed/racket/unsafe)
> ; import with a bad type
> > (unsafe-require/typed racket/base [values (-> String Integer)])
> ; unchecked call, the result type is wrong
> > (values "foo")
> - : Integer
> "foo"

Added in version 1.3 of package typed-racket-lib.
Changed in version 1.6: Added support for struct type variables

> > syntax

> > (unsafe-provide provide-spec ...)

This form declares exports from a module with the same syntax as the provide form.

Unlike provide, this form is unsafe and Typed Racket will not generate any contracts that correspond to the specified types. This means that uses of the exports in other modules may circumvent the type system’s invariants. In particular, one typed module may unsafely provide identifiers imported from another typed module.

Additionally, importing an identififer that is exported with unsafe-provide into another typed module, and then re-exporting it with provide will not cause contracts to be generated.

Uses of the provided identifiers in other typed modules are not affected by unsafe-provide—in these situations it behaves identically to provide. Furthermore, other typed modules that use a binding that is in an unsafe-provide will still have contracts generated as usual.

Examples:

> > (module t typed/racket/base
> (require typed/racket/unsafe)
> (: f (-> Integer Integer))
> (define (f x) (add1 x))
> ; unsafe export, does not install checks
> (unsafe-provide f))

> > (module u racket/base
> (require 't)
> ; bad call that's unchecked
> (f "foo"))

> > (require 'u)
> add1: contract violation
> expected: number?
> given: "foo"

Added in version 1.3 of package typed-racket-lib.
Changed in version 1.8: Added support for re-provided typed variables

> > syntax

> > (unsafe-require/typed/provide m rt-clause ...)

Like require/typed/provide except that this form is unsafe and will not generate contracts that correspond to the specified types to check that the values actually match their types.
top ← prev up next →