Thread overview
Confusing behaviour of array member assignment when calling local function
Jan 05
monkyyy
January 04

Hello all,

I've encountered an unexpected behaviour in the D language, where assigning the result of a function that grows an array to a value in that array ends up modifying the old memory used previously by that array. This seems counterintuitive to me in the sense that it feels logical that the lvalue to be assigned to should be evaluated after the function has been evaluated, but this behaviour implies that part of the lvalue was evaluated before the function.

A minimal reproduction of the issue I'm describing is attached below:

import std.exception;

void main() {
    auto v = new ulong[1];
    size_t appendAndGetLength() {
        v ~= [10, 10, 10, 10, 10, 10, 10, 10, 10, 10];
        return v.length;
    }
    v[0] = appendAndGetLength();
    // Works if we do the following instead
    // auto v0 = appendAndGetLength();
    // v[0] = v0;
    enforce(v[0] == v.length);
}

When running this code, it fails the enforcement because v[0] evaluates to 0 at the end, this ceases to be a problem if I introduce a temporary variable. I am confused as to why this is the case, and why adding the temporary fixed it. Can someone please help me determine why this is happening? It seems counterintuitive, and almost feels a bit like a footgun.

I tried looking in the spec for references to why this was happening, the closest I could find was a footnote about undefined behaviour if aliased reference types are assigned. I believe that this shouldn't apply in this case, because while the lvalue of the assignment is a reference to the array, the rvalue is a size_t (the result of evaluating the function).

January 05

On Saturday, 4 January 2025 at 23:11:58 UTC, Sahan Fernando wrote:

>

almost feels a bit like a footgun.

because it is

[] is both a dynamic array and a reference; dont do both at once

It a #wontfix

January 05

On Saturday, 4 January 2025 at 23:11:58 UTC, Sahan Fernando wrote:

>

Hello all,

I've encountered an unexpected behaviour in the D language, where assigning the result of a function that grows an array to a value in that array ends up modifying the old memory used previously by that array. This seems counterintuitive to me in the sense that it feels logical that the lvalue to be assigned to should be evaluated after the function has been evaluated, but this behaviour implies that part of the lvalue was evaluated before the function.

A minimal reproduction of the issue I'm describing is attached below:

import std.exception;

void main() {
    auto v = new ulong[1];
    size_t appendAndGetLength() {
        v ~= [10, 10, 10, 10, 10, 10, 10, 10, 10, 10];
        return v.length;
    }
    v[0] = appendAndGetLength();
    // Works if we do the following instead
    // auto v0 = appendAndGetLength();
    // v[0] = v0;
    enforce(v[0] == v.length);
}

So what is happening here is the left side of the assignment is being evaluated first. Then the right side. The right side alters v by appending (it must reallocate to accomodate the new values), and therefore you assign to the old v.

This can be demonstrated:

void main() {
    auto v = new ulong[1];
    auto oldv = v;
    size_t appendAndGetLength() {
        v ~= [10, 10, 10, 10, 10, 10, 10, 10, 10, 10];
        return v.length;
    }
    v[0] = appendAndGetLength();
    enforce(oldv.ptr !is v.ptr);
    enforce(oldv[0] == v.length);
}

A dynamic array (or slice) is simply a pointer and a length. It is not a reference into an array object (many other languages are like this, D is not).

You can read more about how arrays work here: https://dlang.org/articles/d-array-article.html

-Steve

January 05

On Sunday, 5 January 2025 at 02:33:51 UTC, Steven Schveighoffer wrote:

>

So what is happening here is the left side of the assignment is being evaluated first. Then the right side. The right side alters v by appending (it must reallocate to accomodate the new values), and therefore you assign to the old v.

...

You can read more about how arrays work here: https://dlang.org/articles/d-array-article.html

-Steve

Ok, that article helped clear up some of the misunderstanding, I guess it makes sense why it works the way it does. It still feels a bit counterintuitive, but I guess I should just treat it as another thing to avoid doing by accident (similar to modifying a collection while iterating over it). Thanks for the reply!

January 06

On Saturday, 4 January 2025 at 23:11:58 UTC, Sahan Fernando wrote:

>

Hello all,

I've encountered an unexpected behaviour in the D language, where assigning the result of a function that grows an array to a value in that array ends up modifying the old memory used previously by that array. This seems counterintuitive to me in the sense that it feels logical that the lvalue to be assigned to should be evaluated after the function has been evaluated, but this behaviour implies that part of the lvalue was evaluated before the function.

https://dlang.org/spec/expression.html#order-binary says:

>

Implementation Defined: The order of evaluation of the operands of AssignExpression.