Can reframe __rvalue as an intrinsic function?

[TurkeyMan]

Is it possible to implement the logic for __rvalue as a function call node rather than a base expression? This can allow more flexibility, gain access to UFCS, and also alias, etc.

Then when druntime is ready to integrate move semantics, it can do:
alias move = __rvalue; in place of the old bespoke function.

[WalterBright]

Since __rvalue has special meaning, it can't be a function symbol. There may be another way to do what you ask, but it would require some rejiggering of the language rules. I know that __rvalue is unattractive looking, but calling it move would have a high probability of breaking existing code.

[TurkeyMan]

I agree it not be called move because it will break code. But it should be a function that can alias move = __rvalue in the future.
I imagined it might be possible to do something like; instead of expr.isRvalue which you've done everywhere, you could do cast(RvalueNode) !is null, which if non-null gives you the same test as expr.isRvalue, and then in the semantic just take the argument expression as the rvalue.

The most important thing is that we can alias __rvalue() so the library can rename it in the future.
Hard-coding UFCS expression in the grammar is an option too I guess, but it seems like there might be other edge cases appear? If it can be framed as an intrinsic function call with hard-coded special semantic logic... seems easier?

[tgehr]

Note that I don't think __rvalue is move. __rvalue is more low-level. If you __rvalue the same location twice, aliasing may result between by-value parameters. (I have argued in the past that this could be considered not memory safe.) With a safe move intrinsic, additional aliasing should not result even when it is used inappropriately (there should be either an error or additional dummy objects being created).

I.e., I think __rvalue is a low-level tool that requires some care in usage, while move should not have such pitfalls.

[TurkeyMan]

@tgehr yes, we've talked about this, and I agree. I think that thing has to be en elaborate intrinsic though, and at least in the meantime we need a primitive one. I specifically suggest using alias that way because it allows flexibility to easily replace the implementation with whatever is most appropriate as it becomes available.