"zero-cost abstractions" means "zero extra cost". Everything has a cost. The borrow checker has zero runtime cost though, as it's entirely at compile time.

I meant to suggest that opt-in features for FP style programming might be accepted, since there doesn't seem to be an actual ban on non-zero-cost abstractions.

Re "extra", I'm not sure what you mean - does it mean that the abstraction is implemented efficiently, but still has the cost that is usually associated with that abstraction? For example, dynamic dispatch is as fast as a DIY dynamic dispatch in assembly?

The borrow checker, AFAIU, has a cost in that it forbids some (more efficient) shared data accesses that it can't prove safe but still are.

> For example, dynamic dispatch is as fast as a DIY dynamic dispatch in assembly?

Yes, zero cost means you could not implement it in a more efficient way by hand.

> The borrow checker, AFAIU, has a cost in that it forbids some (more efficient) shared data accesses that it can't prove safe but still are.

This is not what it meant with "cost" in this context. It is zero cost because it only runs at compile time. That it rejects some valid programs is irrelevant, because it is zero cost for the programs it accepts.

Interesting. But I think restricively molding what can be compiled can also be an abstraction cost. Maybe it's more one of those "you know it when you see it" things?

There is certainly a cost, I'm just not sure I would call it abstraction cost. Is memory safety an abstraction?

Safe Rust has runtime costs as well (mostly bound checks).

Rust's bound checks are cited a lot here on hn as a performance concern but in practice I rarely encounter them because in rust you mostly use the iterator API for loops and it doesn't need bound checking.

For an illustration of a safety-related runtime cost that you almost always have to pay, Uft8 validation of strings is a better example IMHO.