I'm the one asking YOU for reasons why immutable interfaces should be used over mutable ones ;-) You are the one making a proposal in favor of immutable interfaces. Aside from being able to represent the functional paradigm in C++, what are the benefits from your point of view? I've read several papers, and I've used several similar libraries, but I want your experience stories because I respect your talent and experience. Why should the interfaces for string (or other boost libraries) be immutable? I am unaware of an immutable implementation that provides transparent performance cost. I'd be most interested if you know of one. BTW, just for a fun story, working in the kernel and in certain parts of the government, I've learned that benchmarks mean almost nothing, unless you REALLY know all the details of what is going on. One of my first jobs as a kernel developer was to improve performance of our scheduler. I was able to find a few clever optimizations, but the best one was to "configure" the system for the type of operations being run and change the scheduling policy to something that favored the "recognized pattern" which ended up putting our product at the very top of every price/performance index available. Special code for tests is against the rules, and we certainly did not do that. However, you are allowed to configure the kernel, in any documented manner. You are also allowed to "recognize" certain patterns and change behavior in response to those execution patterns. Recognizing the interesting characteristics of those benchmarks were pretty simple (and could reasonably be justified as recognizing a class of program characteristics common to industry usage).