20328, "benharsh", "Memory.Initialization: moveInitialize function signature", "2022-07-29T16:29:14Z"
The current signature of moveInitialize is:
proc moveInitialize(ref lhs,
pragma "no auto destroy"
pragma "error on copy" in rhs)
There are a couple of changes we should consider making here:
Formal Names: src/dst
We are currently using the formal names lhs and rhs, but this seems inconsistent with the choice of src and dst/dest elsewhere. Should we make this change here as well?
Two functions for better error messages
Currently the formals for this function are fully-generic. moveInitialize will compare the static types and if they differ will issue a compilerError with a nice message. The documentation says:
:arg lhs: A variable to move-initialize, whose type matches ``rhs``
But that text might be easy to gloss over, and a user might expect the function signature to present that information.
One way of dealing with this issue could be to create two separate functions: one with type constraints and one without. The fully-generic function would always issue a compilerError, relying upon function resolution to know that the types are mismatched:
pragma "no doc"
proc moveInitialize(ref lhs,
pragma "no auto destroy"
pragma "error on copy" in rhs)
proc moveInitialize(ref lhs : ?T,
pragma "no auto destroy"
pragma "error on copy" in rhs : T)
I would recommend no-doc-ing the compilerError version.
"error on copy"
This pragma exists to capture the case where the compiler inserts a copy for the rhs argument, when what we really want is for the compiler to have 'moved' the argument in for us. This is useful behavior that can prevent problems for the user, but this behavior is currently undocumented.
How should we go about explaining the behavior here when the cause (the pragma) is invisible in documentation? Should 'chpldoc' do something for us? Or is it enough to mention some special compiler-assisted error checking?
Return type
We should specify the return type as void.