On Sunday, 1 October 2023 at 13:51:35 UTC, Imperatorn wrote:

OK in any case the forum seems to be very helpful. Thanks to all for your help.

On Sunday, 1 October 2023 at 13:24:27 UTC, dhs wrote:

The complexity is from the way d does operator overloading and indexing.

It should be pretty straightforward. I’ll see if I can post a simple wrapper.

-Steve

On Sunday, 1 October 2023 at 13:27:37 UTC, Adam D Ruppe wrote:

It may not be a problem in practice. My concern was performance, because each time we add an element to the array, the garbage collector has to map the slice to the allocation it belongs to.

On 10/1/23 10:34 AM, Steven Schveighoffer wrote:

I didn't tackle any attribute or memory safety issues, or many operator overloads, but this is going to be reasonably close. It should make a copy of the data when copied.

Note this still uses the GC for storage, and when expanding, uses the GC to fetch the capacity (this could be done in one call, but meh).

Some niceties of builtin arrays may not work, but this is somewhat of the cost you pay for trying to make a custom type.

struct VTArray(T)
{
    private T[] _storage;
    private size_t _length;

    const size_t length() => _length;

    void length(size_t newLen) {
        if(newLen <= _storage.length)
            _length = newLen;
        else
        {
            _storage.length = newLen;
            _storage.length = _storage.capacity;
        }
    }

    inout this(ref inout(VTArray) other)
    {
        this(other[]);
    }

    inout this(inout(T)[] buf)
    {
        auto x = buf.dup;
        x.length = x.capacity;
        _length = buf.length;
        _storage = cast(inout)x;
    }

    ref inout(T) opIndex(size_t idx) inout {
        assert(idx < length);
        return _storage[idx];
    }

    void opOpAssign(string s : "~", V)(auto ref V other) {
        static if(is(V == T[]))
        {
            immutable avail = _storage.length - length;
            if(avail < other.length)
            {
                _storage[length .. $] = other[0 .. avail];
                _storage ~= other[avail .. $];
                _storage.length = _storage.capacity; // expand to capacity;
            }
            else
            {
                _storage[length .. length + other.length] = other;
            }
            _length += other.length;
        }
        else static if(is(V == T))
        {
            if(length == _storage.length)
            {
                _storage.length += 1;
                _storage.length = _storage.capacity;
            }
            _storage[_length++] = other;
        }
        else static if(is(V == VTArray))
        {
            this ~= other[];
        }
    }

    void opAssign(T[] arr)
    {
        _storage = arr.dup;
        _storage.length = _storage.capacity;
        _length = arr.length;
    }

    void opAssign(VTArray vtarr)
    {
        this = vtarr._storage[0 .. vtarr.length];
    }

    inout(T)[] opIndex() inout => _storage[0 .. _length];

    void toString(Out)(auto ref Out output)
    {
        import std.format;
        formattedWrite(output, "%s", this[]);
    }
}

void main()
{
    auto arr = VTArray!int.init;
    arr ~= 1;
    arr ~= [2,3,4,5];
    import std.stdio;
    writeln(arr);
    auto arr2 = arr;
    arr2[0] = 5;
    writeln(arr);
    writeln(arr2);
    arr2 ~= arr;
    writeln(arr2);
}

This should give you a reasonable head-start.

-Steve

On Sunday, 1 October 2023 at 17:21:32 UTC, Steven Schveighoffer wrote:

It does. Many thanks!

On 10/1/23 1:13 PM, dhs wrote:

FWIW, there is a cache that makes this decently fast, so it doesn't have to go all the way into the GC to get all the information for every append.

But it most definitely not going to be as fast as reading a local "capacity" variable.

-Steve

On Monday, 2 October 2023 at 02:56:33 UTC, Steven Schveighoffer wrote:

Sure, I saw that, it obviously works pretty good.

I think it's worth mentioning that D slices are similar in concept to Go slices.

In Python, lists are reference types too but slicing creates a copy (so, 'b = a' shares, while 'b = a[:]' copies.) JavaScript arrays are similar to Python in this sense.
C++ and Rust use distinct types for the resizable array and its view, and the view must not outlive the array.

D and Go slices have advantages but can be confusing. I don't have a solution, but if anyone is interested, the relevant discussions about slice confusion in the Go community apply to D slices as well.

On Wednesday, 4 October 2023 at 10:51:46 UTC, dhs wrote:

I don't believe slice confusion in D is the same as God.

https://he-the-great.livejournal.com/48672.html

D manages to avoid stomping, while Go provides no clear ownership when slices are at play.

And here is the slices explained
https://dlang.org/articles/d-array-article.html

On Thursday, 5 October 2023 at 16:57:00 UTC, Jesse Phillips wrote:

Thanks for the link. It actually demonstrates my point: he gets the same results from D and Go until he appends elements to the slice. It is then that things get confusing.

Obviously, the implementations are not exactly the same: for example, in Go 'capacity' is a field whereas in D it is a calculated property. But they are similar.

Here are some quotes from Go users:

"the issue of Go's slices is that they act as both a dynamic array and a slice viewing a portion of one. The two uses conflict with one another, and the interactions are full of traps. "

https://news.ycombinator.com/item?id=28344938

"the behaviour is logical based on how Go works. The criticism is instead that it works this way in the first place. The reason it's like this is that slices were attempting to address two separate use cases — growable arrays and subarrays"

https://www.reddit.com/r/golang/comments/6qizjq/fucking_go_slices/

Quote: "Welcome to go! This is one of the language quirks."

https://www.reddit.com/r/golang/comments/10b4ofx/confused_about_array_and_slices/

Others pointed out that slices work well. My points is: if you're thinking about a change it's worth reading the Go discussions, because their slices are similar in concept.