In the upcoming C++23, the mutable string_view proposal is under review for inclusion in the next Standard Library. As we all know the current immutable string_view has two members, a const pointer to a constant char array and a constant length whereas in the mutable sibling, both members are modifiable. Let me illustrate with a simple situation where this mutable class comes handy.

Consider this XML snippet and imagine a mutable string_view pointing to the contents of Name attribute.

<Company Name="Ben &amp; Jerry" />

This is the contents of Name attribute before unescaping & to &.

Ben & Jerry

This is the contents of Name attribute after unescaping. It became a shorter text, so the char array and length in string_view has to be changed. This poses a problem for current immutable string_view but not the mutable one for this scenario.

Ben & Jerry

What if the mutable string_view is set to a longer text? Then memory has to be allocated on the heap. The important question is who is in charge of deallocating this memory? Mutable string_view or developer? A heap allocation can always be tracked and deallocated by the object before it goes out of scope! Some might argue this goes against the zero-cost abstraction principle. Or that responsibility can fall on the developer; to do that, the address in the member pointer shall be checked to fall within that boundary of the whole XML string, if it isn’t, it must be allocated outside and shall be deallocated manually. This is fiercely debated issue from the camp who see this manual mechanism as a unsafe hotbed for memory leaks.

The main draw to mutable string_view is it can yield considerable gains in performance under the assumption that most mutable string_view objects remain unchanged or even it does mutate, it is to a shorter text than to a longer one. Longer text case should be an occasional occurence but it can be dealt with deftly when circumstance calls for it. The C++ developers, around the world, look forward and welcome mutable string_view in its Standard Library.

“Mutable string_view is what string_view should have been in the 1st place!” – Chandler Carruth

“Zero-cost abstraction is the guiding principle behind the design of mutable string_view and it should be the direction going forward with future proposals!” – Herb Sutter

“Mutable string_view will undeniably help bring forth other innovations like mutable span, just like what typelist did for tuple and CTRE.” – Andrei Alexandrescu

“That’s it! I am coming out of C++ retirement to teach mutable string_view” – Scott Meyers

“Mutable string_view should be properly named as enough_rope_to_hang_yourself!” – Bjarne Stroustrup

Before anyone mount a serious commentary to this blog post, take a good look at the posting date!

Disclaimer: None of the abovementioned persons made the testimonials listed in this blog. The testimonials are fully made up.

You may like 2019 April Fool post: C++23: fullptr to replace nullptr and 2021 April’s Fool post: C++23: -> and :: to be replaced by . operator. Enjoy!.