Is this essentially dictionary compression ?
On 64-bit machines though strings shorter than 8 bytes are better off not interned.
This will not work for the average struct, and if you do use it, you now no longer can include any, for example `[]byte` fields in the struct or else it will no longer compile.
I always find it funny that `string` is comparable, but `[]rune` and `[]byte` are not.
For slice types it's more complex because there is mutability implicit aliasing. And the backing array pointed at may change. I guess the latter should point us toward deep value comparison for slice types since any other comparison would be quite flimsy.
This is an instance of dictionary encoding where terms are words and dictionary code space is the entire machine addressing space (heap).
The disadvantage of this approach is that you can only "deduplicate" words that are exactly the same and you cannot remove duplicated substrings. Another disadvantage is that the dictionary code size is 8 bytes which means you achieve some saving only for words that are longer than 8 bytes (plus some other overhead for the interning index).
Compression algorithms that use dictionary encoding typically use code/symbol sizes smaller than 64 bits, often using variable length encoded numbers encoded with some kind of entropy coding that is able to use short bit sequences for codes representing dictionary entries appearing often and longer bit sequences for less frequent ones.
But the idea is the same. During decompression you read each "number" from the compressed stream and you use it effectively to index an array that contains the target (sub)strings.
The algorithm in the post just interprets the 64-bit dictionary code as an index in the giant array that is the machine addressing space.