It could be helpful to define Ractor::Moved#inspect and output the source location of when the data was moved. If preferred, it could raise an error with this information:
x = []
Ractor.new{ receive }.send(x, move: true)
p x # => "Data was moved in `example.rb:4`"
# or
p x # => "Data was moved in `example.rb:4`" (Ractor::MovedError)
Also @zverok (Victor Shepelev) and myself were wondering if there was a technical reason to freeze Ractor::Moved? If not, is it only to "force" people to use refinements (which are allowed on frozen classes)? It's already known that it is in general a bad idea to modify builtin classes, so it's not clear to me that freezing that class is best.
Maybe refining the message from method_missing is the best and simplest. (giving info that object was moved, and where).
I would also unfreeze the class unless there's a good reason not to.
Discussed with ko1, who said he is afraid that unfreezing the class might create issues, as implementation is quite special. Possible implementation of #inspect for Ruby 3.1
Two things to keep in mind:
usecase for unfreezing the class would be to implement #inspect in pure Ruby for 3.0, for example.
it is possible to refine frozen classes, including Ractor::Moved, so freezing that class may not have the desired effect?
I don't think providing #inspect is good idea because any methods should respond to the moved object.
Otherwise there is possibility to ignore the accessing moved objects.
I prefer to show the moved location in the error message.
x = []
Ractor.new{ receive }.send(x, move: true)
x.size
...:in `method_missing': can not send any methods to a moved object (moved at foo.rb:123) (Ractor::MovedError)