Bug 24510 – Perfect forwarding and explicit move should be compiler intrinsic and have operators

Status
NEW
Severity
enhancement
Priority
P1
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2024-04-16T16:14:08Z
Last change time
2024-12-13T19:34:45Z
Assigned to
No Owner
Creator
Bolpat
Moved to GitHub: dmd#20442 →

Comments

Comment #0 by qs.il.paperinik — 2024-04-16T16:14:08Z
Perfect forwarding parameters of parameters and explicit move requires importing modules (that I have to look up every time and make no sense naming-wise) and is quite unpleasant to look at in code. Last but not least, the current implemenation of explicit move is ctfe-hostile, which makes no sense as the compiler actually can move objects at ctfe. Both operations don’t deserve that; they’re safe and useful. My suggestion would be to make move (and forward, which boils down to either a no-op or an explicit move) a compiler intrinsic. For both of them, there should be unary operators: I suggest `>>` for forward and `<<` for move. ```d f(move(x)); // becomes f(<<x); f(forward!xs); // becomes f(>>xs); // xs can be a pack! ``` They’re both unary prefix operators with the same precedence as the other unary prefix operators. Rationale for the operator symbols: They look very much alike, but that’s happenstance. `>>` looks like the the "fast forward" icon. `<<` looks like an arrow pointing away from the object and indicates: "Whatever is in here goes out of it."
Comment #1 by kinke — 2024-04-17T11:46:05Z
I agree that these should be intrinsics, mainly because the compiler can handle this much much more efficiently than the template bloat of the current library implementations. But I don't think we need new ugly operators for that, simply keeping the self-explanatory `move` and `forward` names.
Comment #2 by robert.schadek — 2024-12-13T19:34:45Z
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/20442 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB