Primitive declaration is unannotated and unboxable

Learning
1

From the build logs of ocaml-sfml.0.08:

# ocamlopt -g -w A -warn-error A -ccopt "-Wall -Werror -Wno-deprecated-declarations" -c -o SFFont.cmx SFFont.ml
# File "SFFont.ml", line 32, characters 0-51:
# 32 | external getInfo: u -> info = "caml_sfFont_getInfo"
#      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
# Error (warning 61): This primitive declaration uses type info, which is unannotated and
# unboxable. The representation of such types may change in future
# versions. You should annotate the declaration of info with [@@boxed]
# or [@@unboxed].

In the file SFFont.ml we have:

type info = { family: string }
external getInfo: u -> info = "caml_sfFont_getInfo"

The stub caml_sfFont_getInfo is in this file at line 111:

CAMLextern_C value
caml_sfFont_getInfo(value font)
{
    CAMLparam0();
    const sf::Font::Info& sf_info = SfFont_val(font)->getInfo();
    CAMLlocal1(info);
    info = caml_alloc_tuple(1);
    Store_field(info, 0, caml_copy_string(sf_info.family.c_str()));
    CAMLreturn(info);
}

I’m using ocaml 4.07.1 and I don’t have this error. I guess it’s a new feature from 4.08.1.
From the docs:
http://caml.inria.fr/pub/docs/manual-ocaml-4.08/intfc.html#sec433
If I understand correctly the docs I have to use [@@boxed], how/where should I add it?
Should I write the following?

type info = { family: string } [@@boxed]

Will this still be compatible with ocaml 4.07.1 (it seems so) and before?

2

The boxed annotation should be on the info type indeed. This annotation should be compatible with all versions of OCaml >= 4.02.3.

This warning 61 is essentially here to help improve the forward-compatibility of your code, in the case where the default were to switch to unboxed.

2 Likes
3

I feel like this warning should say “can be unboxed” rather than the confusingly ambiguous “is unboxable”.

(If I understood it right, which I am not actually sure I did.)

4

(I’m not a native speaker and/but) to me “unboxable” means exactly “that can be unboxed”, can someone explain why “is unboxable” is more ambiguous?

Note: it’s a bad practice to release code that uses -warn-error A in release builds. @fccm, if you have the opportunity to change ocaml-sfml upstream, could you maybe suggest not using this in releases anymore? (If the package doesn’t have an easy way to use different flags for development builds and release builds, then I think that not using -warn-error A at all is the best option.)

5

Yes kit-ty-kate already told me to remove -warn-error A and I did.
I thought when I added it that it was a good idea because I thought it will push me to take care of every warning and thus improve code quality. But indeed it should probably be used only locally, and not for releases.

6

I think you could also interpret it as “cannot be boxed”. I.e. un-boxable rather than unbox-able.

1 Like
7

“unboxable” can be parsed as “un-boxable” (cannot be boxed) as well as “unbox-able” (can be unboxed). My impression is that the parallel with “unannotated” in the warning’s wording makes the incorrect parse more attractive for some reason (perhaps because your brain factorizes the un’s, something like that).

The classic example of a commonly-used word that is ambiguous in the same way is “unlockable.”

1 Like
8

I think a little bit of context helps in this case. Unboxing is something that’s hard to accomplish and is generally desirable, while boxing is the opposite. That biases the reader in the right direction.

9

Thanks for the clarification. I just sent a pull request (#8914) to clarify the warning text.

3 Likes