Originally move when it was in the stdlib as _move was behind a keyword but we
moved it in front to allow for some testing. Now that we are going with a
keyword (which we can't leave in/deprecate) move it behind the move only
experimental flag until this gets through evolution.
I also updated the move function tests to show that this is working. As a nice
bonus, I was able to enable all of the tests also in a non-optimized stdlib.
The error diagnostic tells the user that the compiler can't check the value. It
then instructs the user to make a feature request and provide the test case if
they think it is reasonable. I also provided an option to disable the diagnostic
to unblock people.
The reason why I think this is the right thing to do is we want people to know
that _move means they do not need to worry about the given binding being used
later in the program in some way without having to reason. For now I am doing
this by banning _move on non-lets, non-params. This is implemented by noting
that:
1. _move inserts move_value [allows_diagnostics].
2. The checker always removes [allows_diagnostics] after checking a _move.
Thus we know after we check, any move_value that is still marked with
[allows_diagnostic], it was a _move that we never used in any checking.
I added some test cases where this known triggers. I am either going to
implement some sort of support for performing _move on them or give a more
specific diagnostic. This is just an initial incremental step.
The key thing is that the move checker will not consider the explicit copy value
to be a copy_value that can be rewritten, ensuring that any uses of the result
of the explicit copy_value (consuming or other wise) are not checked.
Similar to the _move operator I recently introduced, this is a transparent
function so we can perform one level of specialization and thus at least be
generic over all concrete types.
