"Node" is the name I used to talk about the cons cells your singly linked list is made up of.
Now 2 things.
First, the tiled denotes unique pointers. Your example was a singly linked list. Singly linked lists have 2 important characteristics: adding or removing the first element is O(1), and the tails of those lists can be shared. With unique pointers, you can't share. By design. If you want several references to a "node", you need to use shared pointers, whose allocation is manage by reference counting or garbage collection. So you have a data structure whose only advantage is O(1) insertion and removal… of the head. That's not very useful to begin with, considering the absurd amount of heap allocation you need to do. Other data structures fare better (vectors, ring buffers…).
Second, your example supposes the existence of a `cons()` function to begin with. If you really want to use unique pointers, you should write a function that accepts values, and wraps them in a pointer instead. That way, you can write `cons('A', cons('B', cons('C', empty)))`. There, no more pesky tiled: they have been factored in the definition of `cons()`. Less repeating yourself for the win.
> are you saying that for every self-referential constructor of an algebraic datatype, the correct thing to do is to write a boilerplate function that simply wraps the constructor and a call to whatever the boxing operation winds up being...?
Not quite. I'm saying the constructor itself should take care of the boxing operation. When devising a data structure, you generally know what it will be used for. It's memory allocation scheme should be a part of it. Hidden, if possible. For instance, unique pointers have value semantics. As such, they're an implementation detail. Leave them out of the interface. If it turns out you didn't need them after all, you can scrap them without breaking outside code.
Hmm, I guess that makes three…