`cast(ref T)...` as shorthand for `*cast(T*)&...`

[TurkeyMan]

Can we enhance cast expressions to do lvalue thunk's?
This classic pattern *cast(T*)&...; there's a lot of cognitive baggage going on there!
We should be able to write cast(ref T)... instead.

[dkorpel]

I think re-interpret casting is ugly by design. cast(ref T) looks like a safe operation.

[TurkeyMan]

We'll it's obviously a @safe violation... so it's not :P
I'm very tired of ugly thunk's. I don't think this is something that affects very many people, since most people don't do this much anyway.

[dkorpel]

Imagine code looking something like this:

import std.bitmanip;
void main()
{
    read!ushort(cast(ubyte[]) [0xAA, 0xBC, 0xDE]);
}

Which then gets changed to:

-    read!ushort(cast(ubyte[]) [0xAA, 0xBC, 0xDE]);
+    read!ushort(cast(ref ubyte[]) [0xAA, 0xBC, 0xDE]);

Is it obvious we're doing a re-interpret cast of an int[] suddenly? To me, it looks like it promotes the rvalue to an lvalue. You have to specifically know the meaning we gave to cast(ref). In contrast, nobody accidentally writes:

-    read!ushort(cast(ubyte[]) [0xAA, 0xBC, 0xDE]);
+    read!ushort(*cast(ubyte[]*) &[0xAA, 0xBC, 0xDE]);

since most people don't do this much anyway

As they shouldn't, but nice-looking syntax makes it much easier to do accidentally or haphazardly.

[TurkeyMan]

Imagine code looking something like this:

import std.bitmanip;
void main()
{
    read!ushort(cast(ubyte[]) [0xAA, 0xBC, 0xDE]);
}

Ummm, no that's not what this is about. Infact, this is invalid in the case you show.

Which then gets changed to:

-    read!ushort(cast(ubyte[]) [0xAA, 0xBC, 0xDE]);
+    read!ushort(cast(ref ubyte[]) [0xAA, 0xBC, 0xDE]);

Is it obvious we're doing a re-interpret cast of an int[] suddenly? To me, it looks like it promotes the rvalue to an lvalue. You have to specifically know the meaning we gave to cast(ref). In contrast, nobody accidentally writes:

I'm not sure what you're trying to demonstrate here, it just looks invalid to me.

-    read!ushort(cast(ubyte[]) [0xAA, 0xBC, 0xDE]);
+    read!ushort(*cast(ubyte[]*) &[0xAA, 0xBC, 0xDE]);

This is invalid code, and so the shorthand I proposed is equally invalid for the same reason; you can't cast an rvalue to an lvalue.

since most people don't do this much anyway

As they shouldn't, but nice-looking syntax makes it much easier to do accidentally or haphazardly.

Aside from the conceptual errors above, which makes me suspect you might not have understood what it is I'm proposing, or why, but generally I don't buy into this point either...
I wouldn't describe cast(ref X) as 'nice looking', but it is clear; and that's the point.
Reinterpret casts are hard to read, and consequently error prone. That matters even more for an unsafe operation.
There are three pieces of relevant syntax to perform a reinterpret cast; a &, and 2x *'s required to be written in the right places distributed throughout the expression. As soon as the type expression gets even a little bit long, it gets hard to see and reason about.

I firmly think writing ref clearly inside the cast is much easier to see and understand.

It has nothing to do with making it 'nice-looking', it's about making a complex and difficult to reason about expression reasonable.

The current situation with the * .. * .. &, it's easy to miss one of these symbols, and it's also easy to mis-type and/or forget to write one... and the thing is; failure to write it correctly doesn't necessarily lead to a compile error; it's roughly equally likely to lead to unintended behaviour.
The pattern as fundamentally dangerous, and I'd like to see it be more explicit, clearly state the intent, and therefore less error-prone.

[dkorpel]

I know that my example is not what you are trying to do. Let me clarify.

I said "unsafe constructs should look unsafe"
You said "cast(ref T) is obviously unsafe"
Then I tried to make a point that cast(ref T) only looks unsafe when you already know what it is specified to do.

I attempted to illustrate this point by giving a hypothetical scenario of someone trying to pass an rvalue to a ref parameter, getting an error, and trying out cast(ref T) thinking it would simply convert the argument to an lvalue, and accidentally ending up reinterpret casting instead. Now you're right that cast(ref T) in your proposal doesn't actually create an lvalue, so the compiler would raise an error before the programmer sees the bug at runtime. I forgot that, and evidently it's not the best example.

I wouldn't describe cast(ref X) as 'nice looking', but it is clear; and that's the point.

My point is, it's not clear. Let me try a different angle: I gave this ChatGPT this promp:

Someone proposed adding a new construct, cast(ref T), to the D programming language. What do you suspect it means?

And it answered:

Hypothesis: cast(ref T) could mean casting a value or variable to a reference to type T, ensuring that the resulting value is treated as a reference (or lvalue) to a variable of type T.

And it gave this code example:

int x = 10;
auto y = cast(ref int) x; // `y` is now a reference to `x`
y = 20;                  // Modifies `x` directly

And that would also be my first impression of the syntax.

But even if the proposed syntax was reinterpret_cast(T), I suspect Walter will disapprove of the idea, because there's precedence of feature request that would improve the aesthetics of things that are ugly by design.

• version(A | B) algebra
• @trusted blocks
• Casting function attributes like pure and @nogc

He's been against all of these. However, if you go through with this, it's ultimately up to him and Atila to evaluate and decide.

[dkorpel]

The current situation with the * .. * .. &, it's easy to miss one of these symbols, and it's also easy to mis-type and/or forget to write one... and the thing is; failure to write it correctly doesn't necessarily lead to a compile error; it's roughly equally likely to lead to unintended behaviour.

If you do this a lot, you can always define your own helper function.

T reinterpret_cast(T, V)(V value) => *cast(T*)& value;

float x = reinterpret_cast!float(0x3F800000);

I know I know, you don't want call instructions, and you don't want the debugger to step into trivial functions like that, but I'm starting to see a pattern here: perhaps we just need to make pragma(inline, true) work like you want to, and then we wouldn't need to implement simple functions as new language features in the compiler.

[TurkeyMan]

My point is, it's not clear. Let me try a different angle: I gave this ChatGPT this promp:

Someone proposed adding a new construct, cast(ref T), to the D programming language. What do you suspect it means?

And it answered:

Hypothesis: cast(ref T) could mean casting a value or variable to a reference to type T, ensuring that the resulting value is treated as a reference (or lvalue) to a variable of type T.

This is exactly correct! That's why I suggest that syntax, because it seems logical and self-evident.

And it gave this code example:

int x = 10;
auto y = cast(ref int) x; // `y` is now a reference to `x`
y = 20;                  // Modifies `x` directly

And that would also be my first impression of the syntax.

The point where GPT failed is not noticing that y was not declared ref, so the initialisation of y was a copy... but the right-hand side of the initialisation was indeed a ref to the original x.
It also doesn't help that ChatGPT is generally super-bad at dlang ;)

[dkorpel]

This is exactly correct! That's why I suggest that syntax, because it seems logical and self-evident.

I gotta admit that it's technically correct, but the focus is clearly on 'ensuring that the resulting value is treated as a reference' (which it fails to do in the code example) and not on re-interpret casting. When I ask about type mismatches, it says:

Given D's emphasis on type safety and avoiding undefined behavior, the compiler would most likely:

Reject cast(ref int) floatVar for type mismatch unless explicitly allowed through unchecked reinterpretation (e.g., cast() without type safety checks).

Of course I don't want to give too much weight to an LLM's opinion, but if the syntax was truly self-evident, there wouldn't even be a discussion here. It doesn't help that cast() already has so many gotcha's / inconsistencies depending on type, CTFE/runtime, and literal value/variable.

[TurkeyMan]

Maybe cast needs a do-over like C++ did 15 years ago...
I do feel that D's cast is a pretty serious language weakness, it doesn't distinguish safe or unsafe casts, and doesn't help you do the right thing in any cases at all.

[dkorpel]

I do feel that D's cast is a pretty serious language weakness

I agree. From the top of my head:

• Defining opCast on a struct locks you out of the default struct cast behavior (Fix Bugzilla 22293: opCast!bool for Nullable phobos#9039)
• Casting arrays sometimes casts the elements keeping length, and sometimes reinterpret casts the array bytes (depends on static/dynamic, ctfe/runtime) and expands/shrinks accordingly
• Empty slices cast to bool can be either true or false

etc.

[ntrel]

As there's no opCast for a pointer, the original pattern is more flexible.

See also #18852 which seems the same. As that says, the feature would allow some @safe reinterpret casts as lvalues, though we might want to see good use cases for those first.

[TurkeyMan]

As there's no opCast for a pointer, the original pattern is more flexible.

I'm not sure what you are saying here?
If you're saying this suggestion subverts opCast, that is precisely the point. This syntax will never call opCast.

See also #18852 which seems the same. As that says, the feature would allow some @safe reinterpret casts as lvalues, though we might want to see good use cases for those first.

Nice to know that Andrei had the same thought.