On Sunday, 6 June 2021 at 14:05:54 UTC, Jack Applegame wrote:

enum DEFAULT = foo();
char[] foo () { return null; }
void bar (char[] arg = DEFAULT);

char[] foo() @safe { return "hello".dup; }
enum WAT = foo();
void main() @safe {
    WAT[0] = 'w';
    writeln(WAT);
}

Error: program killed by signal 11

This is... interesting. I did a bit of digging in memory and the code was actually using int[] (or at least, not char[]), so it was something like this:

import std.stdio;
int[] foo() @safe { return [42, 42, 42]; }
enum WAT = foo();
void main() @safe {
    bar();
}
void bar(int[] data = WAT) @safe
{
    data[0] = 84;
    writeln(data);
    writeln(WAT);
}

The above works as expected (at least, as I would expect). However, change the type to char[] and it SEGV. That's probably because string literals are special and the compiler makes some (bad) assumptions.

However, the compiler shouldn't allow you to use an enum as an lvalue. It used to be able to recognize this, but it broke at some point after v2.080.0.

On Sunday, 6 June 2021 at 15:05:47 UTC, Mathias LANG wrote:

import std.stdio;
int[] foo() @safe { return [42, 42, 42]; }
enum WAT = foo();
void main() @safe {
    bar();
}
void bar(int[] data = WAT) @safe
{
    data[0] = 84;
    writeln(data);
    writeln(WAT);
}

It's definetly a code smell.
Here are much better solutions:

char[] foo() pure { return "hello".dup; }
immutable DEFAULT = foo();

void bar(char[] data = DEFAULT.dup) {
    data[0] = '1';
    // DEFAULT[0] = '2'; Error: cannot modify `immutable` expression `DEFAULT[0]`
    writeln(data);
    writeln(DEFAULT);
}

It uses explicit copying instead of the undocumented "feature" of the enum.

Or just use function directly

char[] DEFAULT() pure { return "hello".dup; }

void bar(char[] data = DEFAULT) {
    data[0] = '1';
    DEFAULT[0] = '2';
    writeln(data);
    writeln(DEFAULT);
}

// works too
void baz(string data = DEFAULT) {}

On Sunday, 6 June 2021 at 10:47:54 UTC, Mathias LANG wrote:

void foo (char[] fmt = DEFAULT_VALUE) { /* ... */ }

Yes, and if the memory layout is like in C, I would expect 'immutable' variables to be addressable (in RO data segment), but not 'enum' constants (which would be simple rvalues, probably directly used as-is in assembly instructions).

On Sunday, 6 June 2021 at 15:05:47 UTC, Mathias LANG wrote:

    WAT[0] = 'w';
}

It doesn't, at least when taking the statement by word. The thing being an lvalue here is WAT[0], not WAT. It gets clearer when a function f returns an array (by value, of course); then, f()[0] is an lvalue, despite f() not being one. Dynamic array elements always have an address, they're always lvalues. The statement [1, 2, 3][1] = 2; type-checks, compiles (as it should, albeit nonsensical) -- and considering that enums are named literals, WAT[1] = 2; isn't much different.

There's nothing stopping you from typing an enum immutable:

enum immutable(int[]) WAT = [1, 2, 3];

Will refuse to have its elements assigned by virtue of immutable.