On Monday, 20 October 2025 at 10:38:23 UTC, Serg Gini wrote:
But I'm not sure about slice capacity. it doesn't make any sense for me when it is non-zero
https://dlang.org/spec/arrays.html#capacity-reserve

Here is a radical proposal.

If the base dynamic array has an initial size and neither it, nor dependent slices can be increased in length, this is a great simplification, and will maintain sharing.
Dependent slices can be changed again and again, and it all works.

It is when allowing appending elements or increasing length of any slice, that things get squirrelly. Extending a non-tail slice forces it to break sharing. Extending a tail slice beyond (capacity - length) breaks sharing.

Once sharing is broken/terminated, the semantics of assignment change. I would imagine that there are few algorithms that handle this neat and clean.

Consider a class NonBreakingSlices that has this general behavior:
1. Constructor has initial length or initial elements.
For simplification, we have slices of int only. Easy to extend with Templates.
   This creates a dynamic array to be shared by dependent slices.
   This foundation dynamic array is the only one allowed to grow.

2. void addSlice(string name, size_t start, size_t after, string basedOn) This would establish name as the slice name, based on a parent slice or base dynamic array.
3. void removeSlice(string name)
   Valid only if has no dependencies.
4. int item(string name, size_t index);
   Getter
5. void setItem(string name, size_t index, int newValue);
   Setter
6. void extend(string name, size_t countItems);
   Valid only if name is a tail slice at this point.
   Would extend foundation dynamic array by countItems.
Would extend slice "name" by countItems by adjusting internal length.

The benefit is that this class could enforce non breaking slices that can increase in length.

IMHO, breaking sharing should result in an exception, instead of copying the expanding slice to another memory location.

If there are valid cases where breaking sharing is intentional and useful, kindly share some of those scenarios.

Reply via email to