Why does referenceability kill language and libraries?

[DerpMcDerp]

In doc/sphinx/intro.rst you mentioned "If you're bored, buy me a drink and ask me why referenceability is the great killer of language and library design that nobody ever talks about."

Have you ever written an article online that goes into more depth on this topic?

[FeepingCreature]

Nope! But the tl;dr is the fact that you can do &variable forces a whole bunch of additional stuff in C-like languages. For instance, it's the main reason you can't do a moving garbage collector. It means you need a stackframe to begin with, rather than just putting variables wherever they may be; it means the layout of the stackframe needs to be stable, which forces a bunch of overhead in the backend - ie. the optimizer needs to prove you never do anything equivalent to &var before it gets rid of the stackframe again. That's not free. In a language with classes, it's a big reason that variables can't just be exposed publically. And in a language with const, it's why you cannot reassign a const variable, or declare a mutable variable of constant fields. That part is very underrated - & is on its own the reason for like half the problems with immutable in D, for instance. There's no reason you shouldn't be able to reassign a variable of a type declared with immutable fields - except that you could observe the fields changing if you took a pointer on them with &.

That's a lot of commitments and compiler costs. And for all those burdensome, expensive commitments, you have to do ..... nothing! You get them for free, as a default feature; opt-out rather than opt-in (and in C, opt-out by "not using it"). That's just silly.

[FeepingCreature]

Oh yeah and all this goes again if you want to have data structures with immutable but readable fields, where two fields need to remain synchronized. You either hide absolutely everything behind get accessors (not free!) or accept that users are able to reassign individual fields and break all your invariants at will. That's more mutability than referenceability, but they're roughly the same concept; neat doesn't even differentiate between "assignable" and "referenceable"; you need mut var to do &var as well.

[FeepingCreature]

If you want this in talk form, the closest is probably my DConf '22 talk on librebindable, a library that exists exclusively because D allows taking the address of struct fields.