On Wednesday, 17 April 2024 at 16:51:41 UTC, Dennis wrote:

// Inside struct LightOptimizer
void moveLightGlobal()
{
    auto light = &this.scene.light;
    light.pos += vec3(...);
}

void onMouseclick(ref GameState gs)
{
    auto ui = &gs.ui;
    ui.startDrag();
    ...
}

Yes I agree. I was just responding to the notion that the DIP would only allow referring to variables, not expressions. To me it doesn't seem to say that, and I'm sure the intended meaning is that expressions are fine as long as they are lvalues.

Error: accessing non-static variable `scene` requires an instance of `LightOptimizer`

Well this can be arguably seen as a "variable" as opposed to "expression", in which case I was wrong - the DIP would be of some (but much lesser) use even if it really allowed only references to variables. But no one is advocating for that restriction so it doesn't matter. At maximum the DIP writing is ambiguous on this matter.

On Friday, 19 April 2024 at 07:23:22 UTC, Nick Treleaven wrote:

(ref p) { CODE }(lvalue);

ref p = lvalue;
CODE

This formulation works IMO but it's better to just write the expression used to initialise the ref variable must be an lvalue, lvalue meaning a value with a memory address. The spec already uses "lvalue" and "rvalue" and includes them in the glossary so it's not a problem.

On Sunday, 14 April 2024 at 23:28:07 UTC, Walter Bright wrote:

Zig tries to be explicit about how an argument is passed: It only allows pass-by-value. If you want to pass by reference, pass the address by value.

While this looks like the same mess as in C, Zig has a whole zoo of pointer types that indicate the various intentions behind a pointer. Zig distinguishes a single-element pointer and a pointer into an array; only the latter allows pointer arithmetic. Zig also distinguishes pointers into arrays that are sentinel-terminated.
A C char* that’s intended to be a string would be typed as pointer into 0-terminated array of char. A C int* that’s supposed to be ref or out would be a single-element pointer to int. Zig also has null indicators, i.e. it distinguishes pointers and slices that can be null and those that can’t be.

It’s a complete 180° from what D’s philosophy is. D style is passing a ref or a slice when you can. This means when you see a pointer, it means something more complicated is going on. One thing that I’d never do because it would confuse my future self: Passing *null via ref. It’s legal in D (not in C++), but I have never seen that being meaningfully used, i.e. I have yet to see an API that takes some ref parameter and the docs say that passing *null does X and Y.

I can see the value in both philosophies. While they seem incompatible, they’re not. D can take a concept or two from Zig.

Notably, in C#, to pass by reference, you have to put ref also before the argument in the function call. This ship has sailed for D. Also in C#, ref variables can be reassigned:

int i = 0, j = 1;
ref int r = ref i;
r = 2; // as if i = 2
r = ref j; // r points to j now
r = 3; // as if j = 3

I’m not saying D should allow reassigning ref, just pointing out that C#’s ref is quite different to D’s ref in that regard.

On Friday, 12 April 2024 at 20:43:50 UTC, Walter Bright wrote:

Why only ref?

ref on local variables is much more like ref on a parameter than a returned object. For parameters, ref is one of three: The others are in and out. Why not also include in? It seems unrelated, but it’s only slightly more general.

An in parameter is const scope, can bind rvalues, and is ref unless the type is small, then it’s a copy. That’s nothing a local variable couldn’t be and the “copy-if-small” semantic isn’t even easily mimicked.

As for out I had some ideas, but those are indeed unrelated with the DIP. (An out local variable would have to be uninitialized and have to be initialized (not assigned) before it is read. The most compelling use case is passing such a variable to a function out parameter.)