There's nothing unreadable (and certainly nothing obscure conceptually) about 'Box<>'. It's just unfamiliar if you don't know Rust. But we'll get nowhere fast confusing readability with familiarity.

I'd be interested to know if anyone has done interesting conceptual and/or empirical work on readability. It seems like a very slippery and difficult concept to me. Readable to whom? Readable in the small or the large?

Readability and familiarity are not the same but closely related. There is nothing inherently more or less readable in the rust or haskell tree example.

I think there is work on "readability", just in another context: Its called typography and orthography. And I think the gist of it is: Do it like everybody else does, first and foremost, strange and unfamiliar equals unreadable.

> I think there is work on "readability", just in another context: Its called typography and orthography.

I think that's a very different case. Maybe some analogies might be drawn between some of that work and some of the lower-level aspects of reading code (related to syntax noise etc), but code readability, if it's a defensible concept at all, is a far more complex and layered phenomenon than letter & word recognition.

The first thing a researcher would need to establish is whether or not readability even exists as a natural kind apart from familiarity. I don't know the field, so this might already have been pursued somewhere.

> There's nothing unreadable [...] it's just unfamiliar if you don't know Rust

Agreed. Note the same applies to Haskell's syntax :)

People confuse "readable" with "based in my knowledge of Java and C, I can't make head or tails of this notation without reading a tutorial first", which in my opinion is not a sensible conclusion.

It's not entirely sensible, but it is understandable. I don't think most programmers are truly aware of how much they know, and how deeply automatic their recognition of programming constructs has become.

Box puts something on the heap and returns a pointer to that thing. Here it is necessary because otherwise the Rust compile wouldn't be able to determine the size (in memory) of a Tree.

Box<T> is a type, so it’s confusing to say it returns a pointer. It holds a pointer.

GP should note that C++’s unique_ptr isn’t an obscurity.

Calling it Box is confusing. unique_ptr would be an improvement for the name, or maybe HeapRef. The problem is exactly that rust chose a misleading name Box (boxed types are something entirely different in most languages) instead of the obvious C(++)/Java-like _ptr, ref, * or & notation/convention

Boxed types in Java are basically the same thing: a heap allocated version of an otherwise stack-allocated type.

I thought the name was pretty clear; when I saw it in some list of different kinds of Rust pointers, I knew what it was immediately.

It doesn't matter if some people are confused, because you can just explain what it is in 3 seconds. What's important for such a ubiquitous type is that the name is short.

> instead of the obvious C(++)/Java-like _ptr, ref, * or & notation/convention

That would be very misleading since Box represents a heap-allocated owned value