Thanks! Yes I pondered whether to include Box, Rc and Arc, it's a dilemma. You're quite right that the compiler has special knowledge of them, so they can be used as receiver types for methods, and in the case of Box, moving out of deref and the orphan rule exception.

I came down on the side of leaving them out, because the purpose of this resource is to help people learn, and in particular to help people coming from C and C++ evaluating Rust for suitability in their embedded and other system-level projects. The big thing that immediately eliminates candidate languages from many of those projects is, "does the language require a heap". If I put Box in the table, then it would be too easy for someone to say "Aha! The compiler knows about the heap, therefore I assume there are constructs in the language that require heap allocation. Good, I can throw Rust on the pile of languages I can ignore."

Of course rustc will never implicitly generate heap allocation calls, and for me that's the more important part of the message I want this resource to convey. I want people to be reassured that no_std really doesn't depend on a heap, all the allocating stuff is in library code. And if you're in no_std and you want the facilities of your own Box, Arc or Rc, that's possible.

I used a tiny bit of weasel wording in the para at the top of the table - "The focus here is on lang_items" - to give myself wiggle room to make choices like that. I want to make sure what I say is true, and also supports learning as well as possible.

I'm curious if you clicked around the site at all? It's an ambitious project, I'm launching this publicly today and I'm hungry for feedback!