Unboxing in JS extended compiler?

progman · January 1, 2025, 8:11pm

I’ve found the syntax of unboxing not to correspond to the RFC

goldfirere/ocaml-rfcs/blob/unboxed-types/rfcs/unboxed-types.md

# Unboxed types in OCaml

This proposal is discussed at this [pull request](https://github.com/ocaml/RFCs/pull/34).

OCaml currently has two attributes that this proposal may easily be confused
with:

* We can mark arguments to external calls as `[@unboxed]`, as [documented in the
  manual](https://v2.ocaml.org/manual/intfc.html#s%3AC-cheaper-call). This
  proposal essentially takes this idea and expands it to be usable within OCaml
  itself, instead of just at the foreign function interface boundary.
* We can mark some types as `[@@unboxed]`, as briefly described in a bullet
  point in [this manual
  section](https://v2.ocaml.org/manual/attributes.html#ss:builtin-attributes).
  This attribute, applicable to a type holding one field of payload (either a
  one-field record or a one-constructor variant with one field), means that no
  extra box is allocated when building values of that type. It is notionally
  separate from this proposal, though there is an interaction: see the section
  mentioning `[@@unboxed]` in its title.

This file has been truncated. show original

ie. not #int32 but int32#, but have not second guessed anything else and the functions box/unbox don’t seem to exist.

Is there a more recent document laying out the syntax?
Or is unboxing simply not as far forward as the other extensions?

Topic		Replies	Views
OCaml compiler development newsletter, issue 2: May 2021 Community compiler , news , compiler-newsletter	8	2778	June 23, 2021
This type cannot be unboxed Learning	4	291	October 3, 2024
Single-field records Learning	3	1246	November 3, 2017
Taking a look: some open OCaml Pull Requests Community	2	933	February 7, 2023
Unboxed Int32.t on 64-bit? Ecosystem	22	1848	September 9, 2021

Unboxing in JS extended compiler?

Related topics