Copy-On-Write (COW) Managed Containers?

[IGotD-]

On Tuesday, 20 October 2020 at 14:56:44 UTC, Ola Fosheim Grøstad 
wrote:
>
> Copy-on-write only makes sense if you intend to make copies 
> without modifying them. That is rather unlikely for arrays. 
> When you create a copy you usually do it with the intent of 
> modifying the copy.
>
> I think this behaviour for std::string came about because C++ 
> didn't get std::string_view until recently. I think it is a 
> flaw.
>
> If you use reference counting throughout like 
> Swift/Objective-C, then I guess you could do it. But it isn't 
> really suitable for low level programming. It is a high level 
> feature.

I can see several cases where you want to do operations on 
slices, regardless if it as string or other type of elements.

Today std::string use SSO (short string optimization) in most 
libraries which means that if the string is shorter than a 
certain size it can be stored inside the class (usually around 16 
bytes) otherwise it must allocate the array. If the string is 
copied it actually copies the data and do not reuse anything. 
Previously which must be several years from now std::string used 
COW and the reason was it didn't scale with multiprocessor 
environments they claimed but I've not seen the actual reasoning 
behind it.

The reason we have string_view is because around C++11 
std::string added the zero termination by default which wasn't 
required before. Now string_view is required because of this and 
you can really discuss if that was a sane choice.

Also, reference counting might very well be suitable for low 
level programming. It's actually a GC method that is used often. 
The Linux kernel is full of it, in a manual fashion of course.

Isn't both the array in std.container.Array and the regular 
built-in array COW in D?